PHP to deprecate MySQL extension

http://marc.info/?l=php-internals&m=131031747409271&w=2

by mildweed • 15 years ago

181 100 15 years ago

marc.info

yinrunning2• 15 years ago

"to do that now"?... What would be a good time to break the majority of smaller sites on the Internet?...

masklinn9• 15 years ago

Meh. They're just talking about deprecating it on the 5.4 horizon so far, not going to break anything

yinrunning2• 15 years ago

I can think of 300 sites that need to be re-coded off the top of my head if this is a hard stop on it. And I don't have time for that. Nor does anyone else. I understand what they're saying, and I understand the need to migrate over time ( i.e. stop using mysql and move to mysqli today ). But they need to be cognizant of how many hundreds of thousands of sites this will potentially effect. This is a security origin, but the effects would be felt in business bottom lines. if ( $hard_stop ), just to reiterate that...

whichdan• 15 years ago

There are tons and tons of hosts that still haven't upgraded to 5.3 - if the change comes in 5.5 or 6, it'll easily be 3+ years before it starts to be an issue.

azza-bazoo• 15 years ago

Sad but true. I love PHP, but it's like the Internet Explorer of (web-)server side languages. First there was the ordeal of dragging folks off 3 and onto 4, then 4 to 5, now 5.2 to 5.3 ... I look forward to writing PHP 6 code in my hovercar ;-)

pavel_lishin7• 15 years ago

I know for a fact that my old employer has one client who's still running 4.0, unless they've decided to pay out the ass to upgrade their spaghetti-coded system.

Considering that a) no out-ass money has been offered me, and b) I'm effectively the only person who could even fix bugs in the system, they're still running 4.0.

Terretta• 15 years ago

> I can think of 300 sites that need to be re-coded off the top of my head if this is a hard stop on it. And I don't have time for that. Nor does anyone else.

The linked email repeated a half dozen times that this would be "soft deprecation", affecting the documentation, not throwing any error in the code.

How, exactly, would that "break" any sites on the Internet?

mscarborough• 15 years ago

Would like to see the same for the 'memcache' lib, which is way older and slower than 'memcached'. The older lib comes up first in most search results and there's no real way for a new PHP user to know the difference.

lowglow• 15 years ago

I concur. A lot of people think memcache is the client and memcached is the daemon. Until you actually do some research and read the wiki page, do you understand that this is not the case.

pavel_lishin7• 15 years ago

Thus I am enlightened.

ecaron2• 15 years ago

The problem is that the newer/better extension, memcached (http://php.net/manual/en/book.memcached.php) relies on libMemcached (http://libmemcached.org/) and they won't release a Windows DLL for it (Google "libmemcached windows", the ensuing confusion is just the tip of the iceberg.) Until you can get PHP's memcacheD extension running on Windows boxes, there's no point to thinking about deprecating the memcache lib.

Sure nobody is really running any PHP sites on Windows boxes, but they're sure as hell developing on them. And while I get that the core PHP devs couldn't find a Windows machine if their lives depended on it, enabling coders on Windows machines is what brought them to their current size - something they've clearly forgot since http://pecl4win.php.net/ died.[/endrant]

r00fus• 15 years ago

I honestly don't understand why anyone would develop on Win and release on Linux, especially for a web-app.

VMWare Player and VirtualBox are free, and it's quite easy to setup an Ubuntu image that mimics your server platform (if you must be untethered)... alternatively put everything in the (private, if need be) cloud.

powertower• 15 years ago

> Sure nobody is really running any PHP sites on Windows boxes, but they're sure as hell developing on them.

First part is somewhat false. Second part is very true.

Having developed, provided, and commercialized a WAMP server that was started in 2003 (http://www.devside.net/server/webdeveloper) I've gain some knowledge of who uses PHP on Windows.

Everyone. In all kinds of situations. There is absolutely nothing lost between hosting Wordpress on Windows vs. Linux. Security, performance, maintainability, etc.

I've also found that around 2009, half of the Apache, MySQL, and PHP downloads from their official sites where for the Windows builds.

These numbers have only gone up since then.

The Windows platform for PHP is critical to the health of PHP. Loose it, and you've lost half of the developers and about 30% of the production deployments.

duskwuff2• 15 years ago

There's also a few other landmines like the "http" extension, which is not part of the standard distribution, and which is completely obsoleted by curl.

pak3• 15 years ago

Yes, yes, yes a million times yes. Every person starting PHP should be taught PDO with parameterized queries from the get go. The internet (and many respectable CS courses) are littered with examples using mysql_query() and string concatenation, half of which train people to create SQLI bugs or don't explain why escaping is needed; it's too late to undo the damage already done but at least people new to PHP will hopefully be told now that there is a better way.

If we had trained people to simply do

    $sth = $dbh->("INSERT INTO folks (name, addr, city) values (?, ?, ?);");
    $sth->execute(array($name, $addr, $city));

in 2005, when PDO first came out, uncountable SQLI bugs would have been avoided, and maybe lulzsec wouldn't be having such a field day in 2011...

eropple12• 15 years ago

Even that way is kinda fragile and fugly, though. I always recommend:

  $stmt = $somePDOObject->prepare("INSERT INTO folks " .
    "(name, addr, city) values (:name, :addr, :city);");
  $stmt->bindValue(":name", $name);
  $stmt->bindValue(":addr", $addr);
  $stmt->bindValue(":city", $city);

Slightly more verbose, but it has the upside of being more resilient.

Groxx• 15 years ago

If you go the resilient route with everything you end up with code that looks like Java code. It's not usually worth it, as when the query changes, odds are you'll be looking at the parameters, and will notice changes. Not true for large queries, of course, but for beginners? They're writing things like the above, where the entire process fits in a single eyefull. Making it more verbose from the get-go means they're more likely to just concatenate strings.

18802• 15 years ago

What would be the difference, apart of the named parameters? I mean, does this add any security?

etherealG2• 15 years ago

resilient to what?

pak3• 15 years ago

Perhaps; to avoid any verbosity for any real code I wrap PDO in something like IdiORM and Paris (http://j4mie.github.com/idiormandparis/) or my fork called Dakota (https://github.com/powerpak/dakota). My point was that you can write a PHP + MySQL toy example with PDO that is just as simple as the mysql_query() garbage but is a million times safer in the long run.

troels• 15 years ago

I prefer:

    $stmt = $somePDOObject->prepare("INSERT INTO folks " .
    "(name, addr, city) values (:name, :addr, :city);");
    $stmt->execute(
      array(
        ":name" => $name,
        ":addr" => $addr,
        ":city" => $city));

since it treats the statement as a function call, rather than some chunk of state that you manipulate.

preek• 15 years ago

Two things sometimes irk me: How much code there is to write for simple DB interaction + coupling of two different languages (SQL + [programming lang]).

In Rails I'd write:

  Folk.create(:name => some_name, :addr => some_addr, :city => some_city)

One line, easily readable and only one language (Ruby).

This is not meant to be a flame post - I'm just asking: Is it the preferred way in PHP to prepare SQL statements yourself?

duskwuff2• 15 years ago

ActiveRecord is an abstraction. Which is good in general, but when you want to get your hands dirty with some SQL it's a pretty serious hindrance.

18802• 15 years ago

Well, if you use a PHP framework or library, of course there are easier and less verbose ways to prepare SQL statements.

I don't think RoR vs PHP would be an apples to apples comparison.

smackfu• 15 years ago

It's only "one language" because the Rails framework is hiding the SQL away from you. You can bolt a framework on top of PHP too.

mh-• 15 years ago

this reply isn't meant to be a flame, but-

Do you not understand why you can't compare Rails (framework) to PHP (language)?

PHP has frameworks with ORM, too.

pavel_lishin7• 15 years ago

> The internet (and many respectable CS courses) are littered with examples using mysql_query() and string concatenation

Not to mention, "PHP: The Good Parts". I almost threw that book out when I hit those parts.

jdunck• 15 years ago

http://www.amazon.com/PHP-Good-Parts-Delivering-Best/product... ...Probably the right move.

mildweed2• 15 years ago

This seems like a relevant time to have a discussion on the merits of PDO vs mysqli. Help all those who need to get off of ext/mysql make an intelligent decision on where to go next.

I'm less interested in features (data layer abstraction) and more interested in performance and security concerns.

masklinn9• 15 years ago

> I'm less interested in features (data layer abstraction) and more interested in performance and security concerns.

They both offer the same security (though I believe mysqli offers more rope to hang yourself with, and PDO's API is simpler and smaller).

In the past, mysqli had the performance edge. It's probably still the case, since PDO is db-independent (PHP bundles a dozen of PDO db drivers in the standard distro) whereas mysqli is db-specific. Mysqli will also offer access to more db-specific features if mysql.

PDO has ditched the procedural style entirely (no PHP4 compat), has a smaller API and lets you use the same API for different DBs (across projects, so you'll hit a MySQL and a Postgres db using roughly the same query API).

sequoia2• 15 years ago

Sorry if this is a silly question but where does MDB2 fit into all this? http://pear.php.net/package/MDB2 It looks like it uses mysqli already, is it superseded by PDO?

gchucky• 15 years ago

I was having a hard time loading it, so in case it goes down, here's the text:

Greetings PHP geeks,

Don't panic! This is not a proposal to add errors or remove this popular extension. \ Not yet anyway, because it's too popular to do that now.

The documentation team is discussing the database security situation, and educating \ users to move away from the commonly used ext/mysql extension is part of this.

This proposal only deals with education, and requests permission to officially \ convince people to stop using this old extension. This means:

- Add notes that refer to it as deprecated - Recommend and link alternatives - Include examples of alternatives

There are two alternative extensions: pdo_mysql and mysqli, with PDO being the PHP \ way and main focus of future endeavors. Right? Please don't digress into the PDO v2 \ fiasco here.

What this means to ext/mysql:

- Softly deprecate ext/mysql with education (docs) starting today - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0 - Add pdo_mysql examples within the ext/mysql docs that mimic the current examples, but occasionally introduce features like prepared statements - Focus energy on cleaning up the pdo_mysql and mysqli documentation - Create a general "The MySQL situation" document that explains the situation

The PHP community has been recommending alternatives for several years now, so \ hopefully this won't be a new concept or shock to most users.

Regards, Philip

imajes2• 15 years ago

@mildweed: the title here is total clickbait. They aren't deprecating anything right now, it's not MySQL but ext/mysql (one of 3 possible mysql libs).

please remember in the future to do that better.

masklinn9• 15 years ago

> They aren't deprecating anything right now, it's not MySQL but ext/mysql

MySQL is the "human-readable" name of ext/mysql.

Source: PHP's documentation http://www.php.net/manual/en/mysqli.overview.php

imajes2• 15 years ago

I see your point but you're nitpicking. MySQL is also the name for the database product, and so it's easy to read this and think that PHP are getting out of the business supporting MySQL.

sequoia2• 15 years ago

Agreed, this was a very shocking/confusing/misleading title. "PHP slated to deprecate ext/mysql for newer mysql extensions" is much clearer, and far less exciting.

pstadler3• 15 years ago

Definitely a step into the right direction! It's just scary how many bad developers are passing unescaped values into SQL statements.

I remember one guy who was a PHP developer at the company for years. He was really good at it though. However during my apprenticeship I asked him about best practices querying databases and showed him my code. Looking at it he said: "Why the hell would someone escape those values? It's a database, not the Pentagon."

pak3• 15 years ago

I think people need to be educated that SQLI bugs (errors in escaping) lead to usability issues as well as security issues. I can't count the number of times I've searched for something on a clearly handmade site and watched in amusement as my search query grows backslashes while paging through the results. Also, single quotes show up in more places than people realize: I've seen them in proper names, street addresses, uploaded filenames... if those things break your app or damage data, that should be a tangible concern.

mildweed2• 15 years ago

And my favorite place, email addresses. Valid. Rare, but valid.

MostAwesomeDude3• 15 years ago

I am both amused and horrified by the reluctance of developers to officially deprecate the extension. One post even suggested introducing E_NEARLY_DEPRECATED to handle this situation. Why can't people simply say, straight-up, that it is deprecated, and acknowledge that that means that it shouldn't be used in new code? It's not that big of a deal, is it?

courtewing• 15 years ago

The problem is that this would be one of the most widely used PHP extensions being deprecated, so they're just being careful. This is not the normal way things are deprecated, but education is a good way to start the process of removing popular functionality from such a popular programming language.

LawnGnome• 15 years ago

Exactly. For something like ereg, it was a lot easier to just deprecate it and go from there. For mysql, it's such a commonly used extension that a softly, softly approach is needed, no matter how much it would be nice to get rid of it immediately.

SeoxyS2• 15 years ago

This is the kind of mess when you have 5 different libraries to do the same thing. PHP should never have allowed there to be multiple MySQL, Mamcache, etc. extensions.

Instead, they should have introduced the new libraries in a big version bump, and immediately deprecated the old and unsafe libraries. A couple languages / frameworks that are good at doing this is Apple with Cocoa, and Ruby / Rails.

pavel_lishin7• 15 years ago

And thus ensured that either you upgrade your version of PHP and instantly break your application, or that you stick with an older version with potential security flaws, and never bother updating again?

Bonus points if you're not actually in control of the version of PHP your web app runs on.

SeoxyS2• 15 years ago

Being forever backward-compatible is a curse that prevents innovation and makes you end up with the mess of a language that PHP is.

Que• 15 years ago

Only 5 different ways to do this?... that sounds like the most concise thing in ALL of PHP.

pstadler3• 15 years ago

As a person who teaches PHP (and probably other languages too), you should definitely tell people not to do following mistakes:

  mysql_query("INSERT INTO table(field) VALUES('".$_POST['input']."')");

and not to forget, a truly classic one:

  include('pages/'.$_GET['page']);

When I started to learn PHP there was a contest between the students: Who brings hosts with vulnerable websites down faster. The trick was to recusrively include the same page (like index.php for example). The most funny thing though was to see the explosively rising load average by including /proc/uptime.

After having some fun, we usually sent emails to the administrators just to not receive any answers and to find the hosts still vulnerable months later...

pavel_lishin7• 15 years ago

I would consider e-mailing the administrators an e-mail with something along the lines of "<img src='http://vulnerable_host/?page=/proc/uptime />"

"The call is coming from inside the house!"

pstadler3• 15 years ago

It was much more fun to send them their own /etc/motd!

icode2• 15 years ago

I wished there was a new PHP syntax that would escape strings before substituting them. Like this:

escaped_query="INSERT INTO t (a,b) VALUES ('$!some','$!thing');

The "!" means "escape this variable".

That would be the easiest way to create queries with escaped parameters.

devicenull2• 15 years ago

Escape for what? MySQL? MSSQL? PGSQL? All have slightly different things that need to be escaped.

jawns• 15 years ago

I've experimented with a variation of this.

Something like ...

  foreach($_REQUEST as $k=$v) {
    $REQUEST[$k] = mysql_real_escape_string($v);
  }

  $query = "INSERT INTO table VALUES('$REQUEST[email]', '$REQUEST[name]')";

Problem is, this only works if you don't plan on modifying any of the values before you stick them in the database.

You could also do something like ...

  $query = "INSERT INTO table VALUES('{$e('email')}', '{$e('email')}')";
  $e = 'esc';
  function esc($v) {
    mysql_real_escape_string($v);
  }

But I think that looks pretty ugly.

icode2• 15 years ago

Hey, the {$e('$value')} idea is interesting.

old way:

  $sql_email=mysql_real_escape_string($email);
  $sql="UPDATE t WHERE id=123 SET email='$sql_email'";

your idea:

  $sql="UPDATE t WHERE id=123 SET email='{$e($email)}'";

Im not yet sure, which one I like more.

Almaviva• 15 years ago

I've never understood why you can't write secure code using string concatenation. It seems to me like all it takes is a reliable "quote" method (with proper escaping of course), and the discipline to use it on _all_ variables that go into a query. The advantage is that queries are sometimes easier to read and maintain when they're written locally like this, without having to jump down to another line to see what a placeholder will actually contain.

I concede of course that this can't work unless there is absolute discipline in a project to quote absolutely all variables, whether you think they are trusted or not.

Am I missing a key point here?

PHP to deprecate MySQL extension

Related Stories