15 ms·
PHP to deprecate MySQL extension
- mscarborough 15y agoWould 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 15y agoI 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_lishin 15y agoThus I am enlightened.
- ecaron 15y agoThe problem is that the newer/better extension, memcached (http://php.net/manual/en/book.memcached.php http://php.net/manual/en/book.memcached.php) relies on libMemcached (http://libmemcached.org/ 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/ http://pecl4win.php.net/ died.[/endrant]
- r00fus 15y agoI 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.
- ecaron 15y agoOnce you've had a change to run in that kind of environment as a full-time job for 40+ hours a week, let me know...
- devicenull 15y agoI've been developing in a similar environment for over a year now. I have a linux VM running apache + associated software, with Samba running. I mount my code as a shared drive, and edit it that way. This means I get the power of linux + linux tools, but I can still run Windows as my primary OS. I am perfectly happy with this setup, and haven't run across any downsides.
- mitjak 15y agoWhat is so difficult to imagine about an Ubuntu machine running server software?
- andrewf 15y agoI've seen it done for years in a reasonably sized team. It actually works really well in a fulltime scenario on a large project, on decent desktop boxes in an office environment. Developers appreciated that significant config changes boiled down to: get all of your local changes into version control, then grab the newest VM image off the network drive. It's significantly more painful when you get out of that environment. If you have lots of projects, juggling VMs is a pain. They take up lots of space. Spinning them up/down takes minutes. You don't just have one working IP/hostname/Samba mount/etc that's always there. The resource hit from running a VM is a bigger deal on a netbook. Etc..
- eropple 15y ago
- powertower 15y 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 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.
- duskwuff 15y agoThere'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.
- yinrunning 15y ago"to do that now"?... What would be a good time to break the majority of smaller sites on the Internet?...
- masklinn 15y agoMeh. They're just talking about deprecating it on the 5.4 horizon so far, not going to break anything
- yinrunning 15y agoI 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...
- wvenable 15y agoIt's being deprecated; so it's not a hard stop. It says so right in the message: "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 mysqli extension has been out for 5 years already, if you've got 300 sites that need to be recoded you might want to get on that. It's not difficult to switch from mysql to mysqli -- the API is very similar. But you have a long time; PHP 5.4 won't even deprecate it and it's not even released yet!
- masklinn 15y ago> The mysqli extension has been out for 5 years already I believe mysqli and PDO were released with PHP 5.0. That's July 2004. That's 7 years ago.
- roel_v 15y ago
- pak 15y agoYes, 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...
- eropple 15y agoEven 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 15y agoIf 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.
- masklinn 15y ago> If you go the resilient route with everything you end up with code that looks like Java code. Meh. Prepared statements are useful when you'll use the it multiple times through rebinding, and for one-shots it's easy enough to have a function taking a parameterized query and an array and doing the annoying crap internally. Then you just write: $result = executeSQL($somePDOObject, "INSERT INTO folks (name, addr, city) values (:name, :addr, :city);", array("name" => $name, "addr" => $addr, "city" => $city);
- mildweed 15y agoThis 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.
- masklinn 15y 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).
- gchucky 15y agoI 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
- imajes 15y 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.
- masklinn 15y 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 http://www.php.net/manual/en/mysqli.overview.php
- imajes 15y agoI 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.
- masklinn 15y ago> 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. No, I don't think it is because it makes no sense at any level of resolution. MySQL is by a very long shot the most common pairing for PHP data persistence, unless the project is taken over by Microsoft (and drops support for anything but MSSQL) there's no way for such a thing to happen. It simply is not a sensible interpretation of the headline.
- pstadler 15y agoDefinitely 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."
- pak 15y agoI 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.
- mildweed 15y agoAnd my favorite place, email addresses. Valid. Rare, but valid.
- MostAwesomeDude 15y agoI 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 15y agoThe 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 15y agoExactly. 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.
- ars 15y agoIf they do actually add E_DEPRECATED to mysql/ext they will probably have a really hard time every depreciating anything ever again. mysql/ext is so popular that all default installations will start hiding E_DEPRECATED, which means that no one will ever again see depreciated warning even for things that are easy to fix.
- MostAwesomeDude 15y agoDeprecation is a signal that it will be removed in the future, not an immediate removal. The entire point of deprecation is that it allows library authors to signal that a thing will be removed in the future, down the road, when everybody as switched to something better. If that mechanism isn't reliable, then apparently there is something wrong with the language community.
- SeoxyS 15y agoThis 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_lishin 15y agoAnd 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.
- SeoxyS 15y agoBeing forever backward-compatible is a curse that prevents innovation and makes you end up with the mess of a language that PHP is.
- pavel_lishin 15y agoI agree, but you don't have to be backward-compatible forever - you can deprecate features gracefully.
- Que 15y agoOnly 5 different ways to do this?... that sounds like the most concise thing in ALL of PHP.
- pstadler 15y agoAs 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_lishin 15y agoI would consider e-mailing the administrators an e-mail with something along the lines of "<img src='http://vulnerable_host/?page=/proc/uptime http://vulnerable_host/?page=/proc/uptime />" "The call is coming from inside the house!"
- pstadler 15y agoIt was much more fun to send them their own /etc/motd!
- icode 15y agoI 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.
- devicenull 15y agoEscape for what? MySQL? MSSQL? PGSQL? All have slightly different things that need to be escaped.
- jawns 15y agoI'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.
- icode 15y agoHey, 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 15y agoI'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?