http://php.net/manual/en/migration70.removed-exts-sapis.php
I actually met a young aspiring web developer who still learned DB-access with mysql_* functions. I urged him to switch to a sane framework like Laravel. Oh boy he was happy in a month and learned bunch of best practices quickly.
...why didn't you taught him about PDO, so he can start with something more universal, not tied to one particular framework that happens to be popular nowadays?!
Then he can learn whichever OR/DM or DAL he might like need (Eloquent, Doctrine, Redbean, IdiORM/Paris etc.), and also be able to pop the hood and debug it when needed.
I never get it why so many otherwise-good PHP devs have their heads full of framework-specific knowledge and have a propensity to fall in love with heavy frameworks like Laravel, or worse, with leviathans like Symphony or Zend ...instead of playing to the language's advantages and using light-weight tools and libraries that would allow them to move faster.
It's easier point to framework that's already using PDO and and making sane defaults and solving bootstrapping problems. Once you've learned bunch of new concepts like ORM in one framework, it's easy to understand other ORs and be able to compare it to DMs.
My own experience with Laravel has been really positive. Actually I was thinking about creating something similar until I learned about Laravel, so it solved lots of existing annoyances regarding PHP coding for me.
Everybody needs to start somewhere and I believe that by nudging towards Laravel, my young friend'll learn more in the long run and in the meantime can concentrate on making services instead of writing home grown PDO helpers and custom routing libraries. They are problems that have been solved already multiple times.
Also, Symfony and Laravel communities are encouraging and teaching about the better ways of doing things so that'll help him in the long run.
In many small project it's more fun and more easier to use $favorite_framework instead of searching for reinvented wheel. There are cases when it's better to do more custom solutions but for many cases frameworks are just awesome
Depending on what you mean by "move faster", I may have to disagree. Besides a one-off script, I can't envision a scenario where using "tools and libraries" would allow you to move faster than using Laravel.
Laravel comes with an unbelievable amount of stuff done for you, right out of the box. Routing, Auth, Database, Queueing, Caching, Asset Pipeline, Templating, etc, etc. If your goal is to rapidly develop an application, there really is no better framework than Laravel to get that going. There's even a vagrant box that's all tooled for Laravel.
TBF, I may have misunderstood what you meant by "move faster".
Edit: Posted this before seeing the other comments suggesting it already, dope
http://www.phptherightway.com https://phpbestpractices.org
Also, I would encourage them to look at different frameworks, not just one. It'll help if they later move onto other languages, as they'll be already exposed to different ways of doing things :)
I only ask as scanning it I see that it recommends IIS7 for production PHP on windows servers. Which I believe you could only get using an unpatched windows 2008 server?
There is some middle ground good practice which is using PDO, or even better Doctrine/DBAL . I don't think Laravel's ORM is that good, and the Active Record Pattern is somehow controversial.
AR is controversial but it is approachable.
In addition, I figure, those old PHP tutorials (code like it's the 2003!) are giving bad example and beginners can't understand the difference or realize that mysql_query + bunch of procedural code per file * 10 can be bad thing.
I should've been a bit more clearer. Laravel taught him bunch of generic best practices (like deployment procedures, GIT, OOP, MVC, etc) and using Laravel Query Builder and/or Eloquent makes the DB code more sane compared to mysql_query.
Laravel isn't the only framework which could've done this but like AR, it's quite beginner friendly :)
I am sure that it has valid use cases, but for a lot of straightforward PHP projects, it's complete overkill and adds more work than it saves (in my opinion of course).
I agree with knowing PDO though, I would say that's required knowledge for any self-respecting PHP developer.
What is controversial about AR?
Thankfully I didn't get the chance to do any damage before I was exposed to modern best practices.
http://blog.a-way-out.net/blog/2015/03/27/php-framework-benc...
Did he already know javascript? if not, why didn't you point him to that instead?
He had already started building something based on old PHP tutorials, what could be more useful if he has some small site to build:
A. Tell there's a nicer and easier way to do it in PHP with well thought framework B. Tell server JS is so awesome (and all the cool kids are using:), you just need to start completely from the beginning
Introducing things gradually can help a lot and lessen the frustration. Nowadays he's really into Vue and React but still likes to handle backends with Laravel :)
Also learning is one of those things that helps if the learning stuff isn't too far away from the skills you already have. Introducing too much at the same time makes learning more frustrating - especially if you want to get something finished instead of trying to multiple ways of doing the same thing.
Languages are learning from each other these days, the new PHP definitely benefited from this trend and is actively evolving itself, which is the major reason I'm to stick with it.
Some PHP developers recommended nodejs over PHP for the future to me, after a few experience I feel PHP may be better for long-term maintenance. Renovation is good, it's just that javascript may have too much of it for me to chew on nowadays.
Wish there will be a light-weight version of PHP, something like micropython or Lua, so I can use it on low-end systems when needed. PHP is still very demanding on resources comparing to other languages, even nodejs can be used on IoT devices with restricted mem/cpu power.
disclaimer: I haven't written anything significant with PHP since too many years.
Modern IDEs autocomplete all the functions, I'm using PHPStorm and as soon as I type 'arr' it shows me a list of all the array functions with parameters listed.
Not perfect, but if I was worried about that kind of thing I'd use Python (which I love) or RoR (which I also love).
The ethos of PHP is to just get stuff done: http://axonflux.com/5-quotes-by-the-creator-of-php-rasmus-le...
I never understood this standpoint. I hear this from the Go community sometimes too. Wouldn't having some sane organization of functions make it easier to "just get stuff done"? Just like in Go, wouldn't generics make it easier to get stuff done?
Number.parseInt is not that bad but I'll take to_json() global function instead of (new System.Web.Script.Serialization.JavaScriptSerializer()).Serialize() (or was it Newtonsoft.Json.JsonConvert.SerializeObject()?) any day.
Sure, names of PHP functions look arbitrary and inconsistent but when you know the name of the function you know everything you need (apart from how to use it which you can quickly and unambigously check like: http://php.net/file_get_contents )
It doesn't have to be one or the other.
In fact, array functions could just be under the same static class, like Array::TheFunction() . It would be acceptable and limit chances of namespace collision .
Or, to keep with the JS example:
JSON.stringify()
This is comedy gold! I almost didn't spot the sarcasm :-D
Also, with the functions in the global namespace you can implement a namespaced copy that takes precedence within the namespace and its children. It can easily confuse people, but I've seen it used to force people away from string functions to their multibyte equivalents (it threw exceptions).
CodeIgniter is still popular and a lot of developers have no clue about namespaces and composer usage. It will really take a _long while_ before php7 becomes commonplace.
It will depend on hosting companies for some public websites and sysadmins for internal business apps. Ironically the sysadmins I know will be the hardest people to convince, for some reasons.
that's basically why as much as I can , I chose solutions with no dependencies when I'm working on apps for internal use (like Go,Nim,..). It solves a whole lot of issues. I just can't stand having to convince someone else to do his job in order to do mine.
I doubt any of those developers are ever going to switch what they're already using unless they are forced by some external factor.
The more serious factor is: if you're on Hackernews, you're at least Elvis or even Einstein. Mort is out of reach for most internet media for programmers.
It's kind of like the situation today with the resurgence of JavaScript. One day the kids of the next decade will be posting snarky attitude basically calling JavaScript users retards because they don't use the cool-kids' PepoCOde. Lame. PHP is still excellent technology, and very relevant still for building dynamic server-side websites.
It used to be that people using JavaScript were made fun of for being "scripters", not "programmers". Everyone knows JavaScript is the language of Mort. Only Franken Elvis uses C.
Specifically, I'm hoping the page load times will be cut in half.
[1] https://twitter.com/official_php/status/669940548128534528
If you tag a commit you better stick to your guns and never change it. You can't just re-tag or re-roll your releases because you found a bug. Bugs happen. Increment your version number, cut/tag a new release, and move on. You will never have a perfect release. Ever.
But one thing which is missing is the nullable types, as currently it's either you always return a string and you can use scalar typing, or you sometimes return null and you can't use it (which I'm okay with)
https://wiki.php.net/rfc/nullable_types https://github.com/php/php-src/pull/1045
With this, it will permit to have even better static analysis "a la" HHVM/hack (i.e detecting that you haven't check for is_null in your code
- Type declarations (this is a HUGE move forwards).
- Grouped use statements, not sure if I like how that looks
- ?? will shorten statements
- Anonymous classes seem a bit odd looking to me
- Unserialize filter is a nice security bump
Anxious to try it out and see the speed improvements I've been hearing about too.
I wonder if people who switched to HHVM, will start using PHP again. HHVM has offered much faster performance than previous versions of PHP. The speed of PHP 7 is at par with HHVM.
"build error".
Wait, what? You just released it, it should definitely work! Clicking that icon[2], checking the failed build[3]:
ERROR: no certificate subject alternative name matches
requested host name `pear.php.net'.
To connect to pear.php.net insecurely, use `--no-check-certificate'.
Really? See what's in http://pear.php.net/
> The server running pear.php.net had a fatal hard disk failure and gets replaced by a new machine this week. Until the new machine is setup, this page is up to let you continue installing PEAR packages via the PEAR installer.
In 2015? Cool.
Connecting to the https website ...
% openssl s_client -connect pear.php.net:443 ... Certificate chain 0 s:/CN=mail.cweiske.de
So you're using CN=mail.cweiske.de for pear.php.net. I don't even know what to say.. Well, happy hacking!
[1]: https://github.com/php/php-src [2]: https://travis-ci.org/php/php-src [3]: https://travis-ci.org/php/php-src/jobs/94372493
Do you actually think there's a point in time where mechanical hard drives are going to last forever? If so I have a bridge to sell you.
Hard disks fail, but if you're hosting something important on them, you might want more than one (to grossly oversimplify things).
>So you're using CN=mail.cweiske.de for pear.php.net. I don't even know what to say.. Well, happy hacking!
Yeah, but it's cool that they used Let's Encrypt.
string random_bytes(int $numBytes);
int random_int(int $min, int $max);
New Features list is at https://secure.php.net/manual/en/migration70.new-features.ph...
My favorite is scalar typehinting by far.
Most modern PHP apps will work on PHP 7.0.0 with little or no extra effort, but if you have a large legacy app, and haven't ever turned on error logging, you may need to fix a bunch of deprecated code usage!
Lots of work.
I only recently discovered https://github.com/migrs/rack-server-pages which allows to simply shove Ruby in HTML the same way as PHP and as a new Ruby dev could expect to be able to do. I think this approach makes learning projects simpler, and at the same has the added value of making people actually learn a lot about those aspects of HTTP that frameworks keep well hidden under their carpet and that can help you become a good web developer instead of "simply" a framework user.
Yes for sure, best practices that frameworks implement are there for a reason, and it's great to have them, but IMHO, this approach has advantages when learning and could also be seen as an essential step to understand what those frameworks you will use next are abstracting and why.
IMHO, what still contributes to new generations of devs approaching PHP, is also its immediateness and simplicity with nothing to do except '<?php' code '?>' and with this comment I just wanted to give a bit more exposure to the fact that a similar solution exists for Ruby too, and that it's a bit of a pity that because of the importance of Rails it got a bit overshadowed.
win-win
almost as fast as hhvm but much easier to adapt
Unfortunately PHP seems to have this reputation. It's not so much the language that is the problem but the people using it. PHP typically had such a low bar to entry that literally anyone could pick it up and do anything and everything with it. And quite frankly there were (and still are) a lot of beginner tutorials out there encouraging people to do very stupid insecure stuff. It now seems to be an image that stuck.
If you take a look at the OWASP Top 10, and any big data breaches recently, they are all caused by human error. SQL injection being the major culprit.
Most of it comes down to being developed ad-hoc with convenience for solving a simple problem right now as the main driving force.
Remember register globals? That was a minor convenience which took ages and millions of exploits to be removed – I remember lobbying for that in the late 90s.
Similarly, you mentioned SQL injection. Unlikely as this may seem now, there was a time when things like prepared statements were an exotic new feature with limited library support and a certain school of programmer thought they were probably too slow. The docs and most tutorials didn't mention things like validation or escaping prominently so most PHP developers were trained to slop everything into strings. When PDO came along, this persisted for too long as well and even after they started recommending placeholders you didn't get something like all of the mysql functions saying “Don't use this, it's unsafe”. I've heard that this has improved but it's been years since I needed to look.
Similarly, look at the lax attitudes toward error handling — errors are ignored by default, database errors or warnings have to be explicitly requested, etc. That's “easier”, saving whole seconds of learning at the expense of millions of successful exploits and hours spent debugging.
PHP is the only lasting language where making code that allows SQL injection is easier than code that forbids it.
PHP includes all the worst practices you'll find on any languages. Javascript has the eval problem - PHP has it too; Perl have the too fluid type system where you can't specify anything - PHP too, except that it lacks Perl's tainted mode; Asp made it easier to create code subject to XSS than code that isn't and is subject to directory traversal - guess what, PHP copied it... and the list goes on and on.
This release fixes still some more problems, but PHP will never become a good language.
This is my general experience with all platforms and operating systems. You have to keep up to date.
PHP was early on the web scene, and like ASP it encouraged a lot of bad practices (like concatenating user input into SQL strings) before people knew better.
These days, in the hands of a competent developer, it's no worse than any other mainstream stack as far as security goes.
A history lesson: PHP was originally known as PHP/FI which meant "personal home page form interpreter". That people started using it for "real work" took everyone by surprise, including the author!
If you're dealing with more mainstream PHP apps like WordPress or Magento, its important to stay up on the core updates but also monitor the plugins and templates being installed. The majority of the attack surface on those apps is in the plugins because they're almost never audited.
As for modern customer apps, written in frameworks like Laravel or Symfony, you're usually fine. Those frameworks are on par with Django and Rails in being very hard to shoot yourself with.
BS. Most PHP4 code runs just fine, as do PHP5 code. Almost no one used object oriented code in PHP4 days (it was slow!), so the incompatible changes aren't a problem. And all you need to do is to search and replace some function names like mysql_* to mysqli_*. Most old code bases from PHP4 days also didn't rely on frameworks at all and were completely written from scratch or copy&pasted together - actually an advantage in this case.
Upgrading an old Python or Ruby code from 1.x/2.x days is a lot of more work (as it always includes upgrading to a recent framework version) than upgrading from PHP4 or PHP5 to PHP7.
That comment looks a bit scary if it's true :(
Python: PURE elegance
Node: io breeze
PHP: ?
Q: is the "module" system still achieved by dumping file content or is there a linking system?
Hostgator, Godaddy...
And all the shared hosts around still stuck at 5.3 or so, this is your time to move forward. At least start offering a PHP7 version, if not a straightway upgrade.
Huge thanks to the internals for their hard work.
The latest release according to php.net [0] is 5.6.15 which come out October 29th of 2015.
Don't quote me on that, but that's my understanding of it.
Yes.
Good.
I haven't laughed this much in a long while. PHP was my first language and indeed I got far away as soon as I knew any better.
Yup, there are two, and they are entirely different.
One uses the historic library, the other uses the new library. Why they decided to do it this way is beyond me.