This is definitely a welcome change. Doesn't really stray too far from the previous design really, it feels cleaner and a lot more modern. I think PHP's lack of nicely designed site doesn't do them any favours in the language wars though considering PHP is viewed as an old and inferior language to others.
I'd just like to clarify instead of responding to the 100 deep comment thread below that I actually use PHP everyday and love the language. The comment about the site was merely an opinion observing the fact that a lack of modern looking website was fuel on the PHP fire. I actually love PHP and since version 5.3 it has become inherently better and the PHP framework Laravel is amazing.
I get the nature of your comment, but you have to acknowledge that this does nothing to address any of the actual issues that many devs have with PHP. It's not just a problem of perception.
There are problems with php? It's not the prettiest language, but people have been building insanely successful businesses on top of it for years. Think Facebook.
It's coyote ugly, but it works. At least most PHP devs don't have the attitude associated with other popular web frameworks. They focus on getting things done.
As a disclaimer, PHP is not my go to language, but I've done some ugly scaling experiments with it. I'm just tired of the PHP isn't cool, let's mock it with no actual valid arguments that is common.
I loved PHP at first too, but the more I started to do serious work in it, the more I grew to hate it. There's so many better languages out there these days, but PHP seems to live off the hype it gained when it was basically a choice between CGI/Perl, Classic ASP and PHP.
PHP ended up annoying me so much that I switched back to Perl (using mod_perl for performance critical stuff). However my latest project is being written in Golang (I know it's all just personal preference, but everything that I hated about PHP, Go seems to get right)
I loved PHP at first too, but the more I started to do serious work in it, the more I grew to hate it.
I can second that. It's great to get into quickly and just hack something together.
But it has lots of problems. Admittedly the devs have begun addressing a lot of issues - like the database access one, where you had just a bunch of functions that didn't even offer auto-escaping and resulted in a lot of unsafe sites - but the old stuff is always kept for backwards compatibility, which means that a lot of sites just continue to be unsafe.
I think a lot of those problems are stemming from the fact that php doesn't have any sort of built-in module system and everything is just on the root level of the language. There are optional namespaces, but even for those they use "\" (like \parent\child), which IMHO is just about the worst choice ever.
Then you have issues like the devs just pushing out a new version even though like 99% of their tests failed (but hey, apparently they at least have tests).
And of course you have the never-ending story of bad php-developers which came into the field because you can just hack stuff together with copy-pasting googled code-snippets and not understanding anything. Seriously, if anyone thinks this issue overstated - it's not. If anything, it is understated.
I have seen productive systems over which money in the tens of thousands of Euros came in which had hidden fields in the HTML containing complete SQL queries which even included the price (apart from the obvious downfall of enabling someone to just POST a 'DROP TABLE' statement, etc.). I have seen systems with something like static 5-digit user authentication tokens that would show up in the URL; You could just sit behind an admin, note the token and be an admin forever. And of course I have seen the ugliest, completely unmaintainable mess of code that would be humanly possible, with no documentation whatsoever (of course).
I also heard from a friend who had to fix something in the C-code making up php about hundreds of lines of codes being copypasted to different locations twelve times. While I haven't verified that for myself, it's not something I'd be surprised about.
Then of course there's the issue of php's design. For one your complete software has to be loaded for every single page view, which is just really fucking inefficient. But having the application not run continuously is also a problem if you want to write any sort of real-time application, which are going to become more and more frequent. You can do stuff like long-polling, but that's just another ugly hack. You might of course be able to have another hacky solution with continuously running php-cli with FastCGI or something like that, but even if that would work in principle, some php script would just die within a few minutes and the site'd be dead.
TL;DR: For small projects that may be hacky and potentially insecure, php is fine - For everything that is supposed to be proper, secure or highly performant I recommend you stay away from php as far as you possibly can. Everything else will just result in huge frustration.
I have seen productive systems over which money in the tens of thousands of Euros came in which had hidden fields in the HTML containing complete SQL queries which even included the price (apart from the obvious downfall of enabling someone to just POST a 'DROP TABLE' statement, etc.). I have seen systems with something like static 5-digit user authentication tokens that would show up in the URL; You could just sit behind an admin, note the token and be an admin forever. And of course I have seen the ugliest, completely unmaintainable mess of code that would be humanly possible, with no documentation whatsoever (of course).
To be fair, only the last thing you list could but doesn't have to apply to PHP, and mostly refer to incompetent practices which could be applied with any language. I'm not going to be a PHP apologist, But I do remember a couple of weeks when it looked like every day there was another exploit in Rails (which is not Ruby blah blah blah) or a problem with exposing app tokens or something. Do I get to say Ruby is a toy language because at some point the YAML parser allowed for remote code execution?
Of course not, because that problem's been (I assume) fixed. The SQL libraries are being deprecated in PHP, it's had parameterized queries for a while. You can do secure cookies and sessions. People just don't -- it's not as integrated a community as with Rails and Python. You can't just say "everybody update your repos" and then the problem goes away, unfortunately. But that's an issue with education, and deployment, not necessarily the language.
I also heard from a friend who had to fix something in the C-code making up php about hundreds of lines of codes being copypasted to different locations twelve times. While I haven't verified that for myself, it's not something I'd be surprised about.
> Once you start having separate operators for each type you start making the language much more complex. ie. you can't use '==' for stings, you now would use 'eq'.
I read up to the point where the author quoted this part from the PHP documentation. That is when I had to stop and go on that page to see if that is actually what they said there. It is.
As an avid PHP user I'm afraid the remaining 1/3rd is truth, the article really is rather biased and in some places not really factual but I'm the last person to deny PHP can improve immensely in some area's.
I once went to a PHP uncon some years ago where 2 members of the php core/extensions team were present, when we got the chance to ask them questions I popped the question "Why doesn't php take the opportunity to fix a lot of the function naming issues, the incosistent argument order, etc ... when releasing the next major version" and their reply was that they don't want to break backwards compatibilty too much. That's plain BS imho. Any non-dot release can break backwards compatibility, especially if it moves the language forward.
I don't agree the breaking BC is a bullshit statement. We all saw how long it took for the majority of PHP users to be able to use PHP 5 due to hosts not upgrading. If all code breaks then we'll end up with two branches of PHP for the developers to maintain for very, very long.
The question of whether or not to break BC basically boils down to doomed if you do; doomed if you don't.
I agree with the idea, but there's room for a coordinated effort nonetheless. From a naming consistency standpoint on strpos vs str_replace, for example, we could have a new set of function names aliased to the old, and let those run in parallel for a while, with deprecation notices on use of the old ones. Ugly? Perhaps, but it's a way forward to standardize the internal function naming without breaking BC overnight.
Not quite for the same reasons it seems. But, since they already do do this, why not take on standardizing function spacing? strpos would become str_pos, etc.
That's why you issue depreciation warnings over the lifetime of the next major release but support both naming conventions rather than just nuke the old function names.
Valid complains that can be made about it, just like about anything else? I've watched people who don't know C++ bitch about C++ for 15+ years referring to lists longer than this one, and it's still one of the most successful languages in the world. PHP is like the C++ of scripting languages - not the prettiest and there are plenty of things to (legitimately) complain about, but stable, well-understood and used by people who are interested in results rather than getting to those results in the most 'elegant' way.
"Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defense against complexity." — David Gelernter
Elegance is not all narcicism, hacking up with none is a recipe for disaster.
I left PHP around the time that v5 was recently released and v4 was still common, as did a lot of people (moving over to Python and later Ruby+Rails). I think a lot of people put PHP now down using their experiences of PHP4 (awful "object" features, irritatingly inconsistent standard library, ...) and PHP4/5 transition problems (which IRC were not really massive, but many libraries didn't deal with the compatibility breaks quickly so there were for a while issues knowing which libs and example code outside the "standard" library were compatible with 4,.x, 5.x, or both) before migrating away.
I assume a lot of the above has change considerably in the intervening years, but I think a lot of people assume instead that it is just as bad as it was when they migrated elsewhere.
That and there is a lot of bad code written in PHP largely due to its perception of being a beginners language (any environment that is easy for a beginner to dive into tends to make writing bad code as easy as it makes writing good code).
> It's not the prettiest language,
That I take as understatement, though I'm still supporting some ancient "classic" ASP code (fingers crossed that legacy will finally be stomped out by the end of this year...) so I can conclusively state there is worse in use out there!
> but people have been building insanely successful businesses on top of it for years. Think Facebook.
Agree. PHP is actually still my goto language for web stuff, even if today its more or less moving to the backend only. The language itself isnt very nice but i simply love the symfony php framework. Ive been using it since 2007 and the 2.x version produces very clean code, is extensible in any way imaginable and just lets me get stuff done really quickly.
I think not many people know how mature the tools in the php ecosystem are today, many people that switched to rails or whatnot years ago still think of PHP as it was 10 years ago, and yes that was horrible.
I use Symfony 2 a lot myself and more recently Laravel 4. While they are definitely solid frameworks I find that the Java-esque level for abstraction in the code base makes debugging a big pain at times. Especially in Laravel 4 which is mostly a layer of static methods on top of Symfony 2.
Also developers who split the project into many bundles...all those directories and namespaces. Really irks me. At least Laravel 4 solved that problem though.
What you are referring to is not "just" static methods. It is known as the Facade pattern and was utilised entirely for the increased testability it provides. In light of that - the comment about debugging rings slightly hollow.
Furthermore Laravel 4 uses the whoops error framework - which provides very in depth errors.
Yes, just quoting the docs: "Facades provide a "static" interface to classes that are available in the application's IoC container."
Your comment on Whoops rings a bit hollow because it was only added a few weeks ago. I was using it before it was added but it certainly helps. That was before Laravel hit 4.0 stable though.
Whenever something didn't work for some reason, digging through the abstraction that is Laravel+Symfony could be frustrating. Thankfully Symfony 2 has good API docs.
You are using a proper IDE with XDebug or Zend Debugger installed, right?
I don't mean this in a snarky way at all. If you're not, and you work with some of the more complex frameworks like Laravel, do yourself a favour and investigate XDebug, and an IDE like PhpStorm that can take advantage of it. It will change your workflow for the better.
The first thing I do with any new framework (which I did with Laravel a few weeks back) is set up a really simple Hello World app and then step through a request loop, start to finish, to get a feel for how the framework sets up a request, dispatches it, and then tears down..
Just from that first exercise, I am immediately more productive with the new codebase..
Having picked up both knackered PHP and C projects, PHP is usually worse as the barrier for entry is much lower meaning that the code barely works in most cases. Plus it's usually plugged into turds like WordPress.
Currently dealing with helping someone upgrade a wordpress+buddypress nightmare. Yuck.
C stuff is easier to refactor as well as you have a strict compiler and valgrind on your side.
thats bad and i have always avoided using limited systems like CMSes or Blogs to use as a basis for big systems because of it. But you are right, alot of the PHP community is based around Wordpress, Typo3, phpbb etc but i have been using PHP for 10+ years and apart from installing Wordpress for blogging i have never used that stuff ;)
I assume you mean ColdFusion (it's been a single word since at least 1999). CF has some definite perception issues, but does have a number of features that go against the grain of the thinking about it: several MVC frameworks, ORM, web sockets, multiple open source engines, an abstraction layer atop the JVM, asynchronous programming options, closures, etc. As for "previous era", it's the same age as Ruby, Java, JavaScript, and others. CF's disadvantage isn't the tech so much lacking an ecosystem such as what has sprung up around options like Clojure, node.js, and RoR.
I would see nothing differently. I would still seek to educate other devs to experience other languages so they might change this problem you've pointed out.
If you know the method you're looking for you can just go to php.net/methodname and it'll take you right there or search if it doesn't match anything. Has done for at least a decade. One of my favorite things about their site.
Read this without snark: do people use on-site search anymore? I and every dev I work with either googles function names or uses hinting in an IDE. Granted, that's a relatively small sample size.
At least using Opera or FF, you can just right-click any text input and create a search from it, so entering "php blah" in the address bar would search php.net for "blah". So yes, I use it on-site searches all the time. Why google for "foobar wikipedia" when I can just enter "wp foobar"? :)
I was doing the same until I realized that googling or binging (let's not rely on google too much) is most of the times faster than using php.net's own search engine. Plus, you're not limited to function names and you don't have to spell them correctly to find the right result.
Fair enough, but I still think that on-site search is desirable in general and many cases. I get that it's too much hassle for small sites, but for bigger ones, I wish they'd at least offer "bingle custom search" additional to their own. Completely outsourcing that is a step back to me, but then again I don't have to pay for the servers so I'll shut up now :D
IMO php "documentation" is different from any other language because the comments can be as important as the official description.
This is especially true when the documentation wording is misleading, or there are some traps when using a function in specific contexts, etc. Or functions only available on recent version will have comments with workarounds for older versions.
You still have to know what you're looking for. The way I work with the Php website - is something like - I kind of remember a function name and try and search for that through a search engine.
What I find difficult on the old site, and this beta site, is getting to the meat. I just can't grok the navigation.
I find the new site harder to read. I can't get to it in Chrome (not working), and it feels very amateurish. The only welcome addition - is being able to vote up comments and autocompletion/suggestions on the search.
If you do any JavaScript development, you'll need to search for "mdc keyword" constantly which is annoying. Having a context-specific search is always better, especially if you bind that to a hot-key in your browser to launch it quickly.
I swear this is the cause of so many "Too Localized" issues on StackOverflow, due to nesting quotes within quotes and getting lost in tags. Echoing html makes things too difficult for beginners.
As someone who uses the PHP documentation all the time, I do wonder if the increased line spacing in the code examples and user comments are going to be a little off putting.
Why would you visit it on an iPhone?! I see the website as a developer resource, and I can't seem to think of a use case when you develop something/need to visit it on an iPhone.
There are still couple of UX problems. For instance once you click an item on upper menu, the section which initially has download and tutorial links is disappeared. There is no way to bring it back to original state. Also again in top menu selected color and hover color is same and confuses user.
Also in some inner pages like this one http://www.php.net/manual/en/index.php left block is empty and page looks like misaligned. It might be better to borrow some ideas from Sphinx generated documentation style.
> For instance once you click an item on upper menu, the section which initially has download and tutorial links is disappeared. There is no way to bring it back to original state.
Load the page, with the tutorial block showing. Look under the PHP logo. See the purple "active" indicator underneath (obviously you do, because you commented on it)? To restore the original state, click the PHP icon.
Yes, we can definitely restore original state by clicking on logo but I guess expected behavior is not reloading page. It supposed to update section like other items do.
I just started learning php (my first programming language).
I am reading Oreilly's Programming PHP 3rd Edition.
Can anyone give me any tips?
(please don't suggest other programming language, I have wasted countless hours trying to decide. I will eventually try to learn other languages but decided to start with php for now. My main interest is webapps, so it would seem that php is the most popular - and easy - choice.)
First, resist the urge to put code in your templates. Because the syntax is the same, it's very tempting to just declare a function or do a query in the middle of your HTML. You'll be happier in the long run if you don't ever get into that habit to begin with. PHP actually recognizes both .php and .phtml as valid file extensions.
I personally try to follow a couple basic rules. .php files should be a single <?php ?> block with nothing outside it, and .phtml files shouldn't use anything but if, foreach, and already defined variables. You'll end up with code that's both cleaner and better structured.
Second, if at all possible avoid Wordpress until you've already got a firm grasp of the language. Wordpress itself has a few decisions that made sense in PHP 4 but are terrible practice now (like using global functions instead of classes) and a few others that, while not technically wrong, were questionable even then (the loop). On top of that, the quality of code in third party themes and plugins varies wildly. If you copy the techniques you see there, you'll learn some awesome tricks, but you'll also learn every bad practice in the book. Until you've got enough experience to recognize the difference, you'll do yourself more harm than good.
> First, resist the urge to put code in your templates
Unless things have changed since I last looked, PHP files are all templates. Last time I used PHP, with symphony, I actually thought PHP was a pretty reasonable templating system.
PHP files are all templates, and when used properly they're relatively good at it. The problem is that, since there's no built in concept of separation, you have to enforce it yourself.
A lot of code written by beginners (myself included, once) will put business logic as close to where it will eventually be rendered as possible, so you end up with code that looks like this
<ul>
<?php
// Thirty lines of database calls and string manipulation
foreach ($results as $result): ?>
<li><?= $result ?></li>
<?php endforeach ?>
</ul>
which makes intuitive sense but quickly leads to an unreadable template. It turns out that, even though you're writing these together, you'll rarely actually want to change them together. So you eventually learn to have template files and nontemplate files.
The .php vs .phtml distinction has no relevance to the compiler. They're only really useful to a human in making that template/code distinction explicit.
If I have, say, a jinja2 template that only contains logic and outputs nothing, is it a template? I would say it is. By which reasoning, yes that php file is also a template. Even if you've got used to pretending it isn't.
Having said which, I'm confused by the lack of a closing ?>. Maybe PHP's parser lets you get away with that though.
...and best practice is to omit it. Since PHP is a templating language any whitespace (other than a single newline) that comes after the ?> will be printed directly to stdout when the file is parsed, which is almost never what the author intends. Letting the parser insert it for you avoids this class of bugs.
As someone who first picked it up in 1998 and has intermittently built apps in it, the biggest tip: use PDO. Many examples online, and what I learned to work with, target the MySQL libs directly, but PDO really saves you a lot of time, and preps you for the concepts of abstraction you find in a lot of platforms.
Absolutely - if you're just starting out then this is a fantastic PHP resource. I would make 2 other suggestions as well:
- Get into the habit of using PHPUnit early. If you haven't come across it yet there are plenty of tutorials on http://net.tutsplus.com/ that cover it's basic use. It may seem pointless to begin with but you'll be thankful later on.
- I know you said you didn't want suggestions for another language and I won't give you any. However alongside PHP I think it would be really beneficial to do a primer on basic computer science. An understanding of concepts such as language paradigms, design patterns and simple algorithms would inform your learning and explain why some of the advanced resources you come across later do things the way that they do.
Without you being more specific, I wouldn't know what to say other than build simple things with it, then more complex things, and keep looking at source of mature projects for inspiration and kicks. Also, modify existing things until they break, then do it again. As long as you're not dealing with sensitive data of yourself or others, don't be afraid of to just poke and pull at things, or to try an idea just to see if it works. Maybe some would advise against that, and maybe they're right, I am not a good programmer by any means. But I have fun doing it, and that's how I learnt.
Learning grammar and vocabulary is obviously the first step, but I think the real fun begins when you learn to express yourself freely, when the path between idea and execution gets shorter, and is less often interrupted by hunting down unexpected bugs. Even though that is possible without knowing all that much of the language, just by getting good at using the bits you do know, it still takes time in any case, and you will have to overcome frustrations. But no matter what language, it's worth it :)
Comment religiously. You'll thank yourself in six months.
You'll save yourself a lot of time if you learn to use Composer (http://getcomposer.org) to manage dependencies, and a templating system (twig, mustache, smarty, what have you) and class autoloading. PSR-0 (https://github.com/php-fig/fig-standards/blob/master/accepte...) is annoying, but it is really convenient once you get past the overhead. If you're on Windows, it really helps to get PHP running from the command line.
Oh well, get ready for a world of inconsistencies! Php is a bit of a mongrel (mongrels are great though,) don't expect a beautifully designed language. The language has been bolted together piecemeal, with a bit of this and that. Function naming style is inconsistant (some with underscores, some without), some parameter patterns feel back to front, in fact don't bother trying to learn too many - rely on your editor and the documentation.
The bulk of my php coding really sits, in foreach loops, if statements (and comparison operators), and the use of arrays. Get to know arrays, build them, loop through them, echo out values, mutate them, they're your friend.
Learn about namespacing, functions and classes. Avoid globals but use the superglobals!
And as with all web programming, understand the browser/server lifecycle of a request. Start with the basics of HTTP.
I like the concept. White layout with bigger, more readable blocks and less wasted space above the fold, but some of the fun they had with the footer and javascript on the page should probably be dropped to make the page load a bit smoother and yeah mobile has definitely not been considered or tested against. I also wonder if these pages are completely dynamic as they seem to load very slowly even in a logged out state.
I don't know if it's because it's "new", but the readability on documentation pages got worse. It's like I'm better off using (e)links to handle php.net searches.
I agree. It's hard to say exactly what they should improve, but I feel that it takes more time to find what I need. Perhaps they should add some colour to give better contrast.
Is it weird that my first observation is that their navigation requires Javascript to function? Because it does: clicking Documentation, Community or Help doesn't get you anywhere, and there's no other way to get to those pages. Also, the website can't seem to decide if its URLs should look like php.net/conferences or php.net/downloads.php.
With the negativity out of the way: MUCH nicer looking site. I look forward to using it the next time I find myself having to write PHP :)
I love PHP, I really do. It's a blinding mess of built-in functions as well as horror due to the incredible shoestorm one needs to create with it to make decent things work. I don't however like the "new" php.net. It's been a year in the making or so, if I'm not mistaking - not only that, it's 5 years in the past, which I guess is better than the previous design, but the "future" comment is just plain wrong.
The menu is not usable for me. It seems like my screen is too small and yet I'm on a 1920px width screen.
The documentation pages are broken too. I guess the flat and typographical design is meant to improve the reading experience and not just for the sake of flatness.
I have the same problem too on Linux. I've found it is fixed by removing the padding-right on the logo and I've tried telling them that on the mailing list. No one will believe me though even if though I have multiple pictures documenting the fact. =/
Would be nice if I could see it. They have this banner at the top:
Step into the future! Click here to switch to the beta php.net site.
Page just refreshes. Tried deleting all my cookies, didn't help.
Edit: Tried in IE10, Firefox, Chrome. I've never visited php.net on this computer before. IMO site is fail since they can't even get their beta site access feature working.
Definitely a welcome news , design looks modern yet the old look and feel is preserved.
keep aside the language wars, people who just want to get things done still use php while others keep on bashing how it sucks .
Changing the font size dismembers the design. It's like it's 2005 again, where everyone had the same screen resolution, and pixel-based layouts were thought to be good webdesign.
Am I missing it, or do they not have an option to see the PHP source of the website anymore? I always thought that was a neat feature to have for a language's website.
This new, rejuvenated website, along with PHP's sexy new language features really seal the deal for me. I have to say, PHP is officially cool again. -sp
Does anyone else think that the best way to promote PHP would be to have a home page that doesn't take 240ms of processing before it starts to download?
I understand where you're coming from; the php.net website is by no means beautiful and the design does lack creativity, BUT, I think that the main purpose of this site is information and no looks. It's all about the documentation and the code examples and the comments. It's a site for a programming language, we don't need beautiful design, animations transitions or any other eye-candy. I think that even the flikr footer is superfluous and we could do without it.
The most important thing is how information is structured and how easy it is to get to it; and from that point of view I am very pleased with the new website. It's a lot easier to read through than the old one and a lot easier to find what you need.
I have to agree. I really appreciate the effort to update the site but it seems like there is even less cohesion than before. I think there are at least 20 different combinations of font family/size/weight/color on every documentation page. The arbitrary sizing especially throws me off. And all the images could use some finessing, like the jaggy comment up/down-vote arrows.
It's a really good start though. I'm heartened to see the site get some love.
