Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP: The Right Way

phptherightway.com

Post reply on HN
Print view View original

81–90 of 233 posts

Re: PHP: The Right Way

#81

Post by socratic »

Are there any good books (or other resources) on modern PHP?

I last used PHP back with PHP3 (and then went C++ => Java => Python => Python/JavaScript => Ruby => Python/R), but a bunch of code I want to read at work uses PHP (with Zend). I no longer remember most of what I learned about PHP3, though obviously the PHP syntax seems to be at least somewhat readable as a sort of amalgam of Perl and C++ syntax and idioms. What does, e.g., Facebook use to get engineers who don't know PHP (but might know C++ or Python) up and running?

Re: PHP: The Right Way

#82

Post by jmadsen »

etanol wrote: post #80

The comments about namespace are somehow ironic: is it very common to find developers that know what classes are but not namespaces? The namespace concept is much simpler than class. Which makes me wonder: who is the target audience?

possibly. Namespaces are very new to php, so programmers who taught themselves via php might not have much experience using or general knowledge of them

Re: PHP: The Right Way

#83

Post by sopooneo »

jasonlotito wrote: post #69
unconed wrote: post #51

Earlier quoted context omitted.

This the wrong way to look at it, and yes, the PHP world always does this wrong because they're too focused on HTML. SQL injection occurs when you're not escaping data while producing output , namely, an SQL query sent to the DB. XSS attacks occur when you're not escaping data while producing HTML, but you don't need angle brackets to do it. allows for XSS injection with just a quote character. Header injection attac…

> the PHP world always does this wrong because they're too focused on HTML. No. The PHP world recommends, time and time again, using PDO and binding variables to queries. I've yet to meet an individual who does it the other way, other than people who are relying on extremely outdated tutorials (7+ years ago). Hell, even this document does. This document, unfortunately, uses the word filter in the wrong way, but the i…

One thing I've run into is that PDO does not let you parameterize the field name in "ORDER BY" clauses. And there are a few other little things that I've wanted to do that it doesn't allow. It may be that me even running into these problems means I'm doing something wrong at a structural level. Regardless, in those statements where I want something to be dynamic, but it's not allowed by PDO, I do an exact equality check against a white list.

Re: PHP: The Right Way

#84

Post by anthonyb »

Udo wrote: post #57
Kudos wrote: post #52

Earlier quoted context omitted.

No it isn't, there's GPG signing and things going on there.

No it isn't, there's GPG signing and things going on there. That's really just Cargo Cult security, isn't it? Signed packages can just as easily be malicious. In fact a repository server could be a much worthier target for the injection of bad code than a single, relatively obscure web project.

The repository doesn't have any access to the developer's private key. That's exactly the attack that they're designed to mitigate.

Re: PHP: The Right Way

#85

Post by chrismsnz »

robertpateii wrote: post #71
lukifer wrote: post #44

While PSR-1 has pretty good universal guidelines, PSR-2 goes too far in insisting on subjective preferences (spaces over tabs, 80-char lines, bracketing styles). We should not pretend that there is a "correct" answer to these choices, just as long as they stay consistent on a per-project basis. All told, I love site, and I hope it keeps iterating. PHP may be ugly, but it's powerful, and most of its bad reputation com…

PSR-2 isn't trying to say that there is one correct answer. Instead they're trying to provide a single answer from the many valid possibilities. "When various authors collaborate across multiple projects, it helps to have one set of guidelines to be used among all those projects"

Exactly, this is what infuriates me about the arguments and whining against PSR-2.

Spaces, Tabs, OTBS, whatever. It doesn't matter which one was chosen, just that something was chosen. Ask the Pythonista's what PEP8 did for their developer's ecosystem.

Also it's important to note that that PSR-2 was based off already existing coding standards like Zend's and Symfony's.

Re: PHP: The Right Way

#86

Post by chrismsnz »

codeguy wrote: post #41
aw3c2 wrote: post #40

curl -s http://getcomposer.org/installer | php is creepy. Never ever run other people's code without at least giving it a glance.

haha. Always good advice. But I checked. It's fine :)

It's fine now until someone hacks their site or poisons their DNS.

Re: PHP: The Right Way

#87

Post by lukifer »

robertpateii wrote: post #71
lukifer wrote: post #44

While PSR-1 has pretty good universal guidelines, PSR-2 goes too far in insisting on subjective preferences (spaces over tabs, 80-char lines, bracketing styles). We should not pretend that there is a "correct" answer to these choices, just as long as they stay consistent on a per-project basis. All told, I love site, and I hope it keeps iterating. PHP may be ugly, but it's powerful, and most of its bad reputation com…

PSR-2 isn't trying to say that there is one correct answer. Instead they're trying to provide a single answer from the many valid possibilities. "When various authors collaborate across multiple projects, it helps to have one set of guidelines to be used among all those projects"

I'm not saying it shouldn't exist; I'm saying it shouldn't be recommended at all as part of "PHP The Right Way". It mixes up arbitrary personal preferences with universal best practices.

Re: PHP: The Right Way

#88

Post by anthonyb »

zdw wrote: post #42
aw3c2 wrote: post #40

curl -s http://getcomposer.org/installer | php is creepy. Never ever run other people's code without at least giving it a glance.

RVM's installation is similar: https://rvm.io/rvm/install/ A far cry from the safer/verified "download this and check it's MD5 checksum" method that I'd prefer. Seriously, fixing package management so we can continuously integrate arbitrary code would be great. Getting arbitrary OS package creation to be almost as easy as pushing code to GitHub seems like a very worthy goal.

md5 is not going to protect you from much, especially if the md5 checksums are hosted on the same server.

Also, pushing random code via apt-get is not going to win you any sysadmin friends. They like their servers to be stable, and their packages to be well tested.

Re: PHP: The Right Way

#89

Post by eli »

Dylan16807 wrote: post #77
jasonlotito wrote: post #67

Earlier quoted context omitted.

Not sure if you are trying to make a joke (and if so, it's incredibly subtle), or you are being serious. In case you are serious, to explain how HTTPS as it's used means anything about the trust-worthiness of the two parties involved?

Look at the original post. "curl -s http://getcomposer.org/installer | php" It's not just about trusting Composer, it's about trusting every point between you and their server. If I want to know that I am actually executing Composer I need to use a secure download method.

I don't disagree with you, but if you've got someone actively trying to exploit you sitting between you and the Internet, you've got bigger problems.

Re: PHP: The Right Way

#90

Post by billpatrianakos »

gbog wrote: post #78

PHP with these guidelines looks like JAVA to me, but without the relatively sane foundations. It is fun how much a very old moralist sentence by Confucius applies well to PHP. He said 其本亂而末治者否矣 which can be translated, in software language development context, as "Build a nice, reliable language on shitty definition? Bullshit!". (The word-by-word translation is "your - root - messy - and/but - leaves/result - governe…

We get it, man. PHP sucks, you're cool/smarter/better because you use something else, and you need to remind us all about it by jumping in every time the letters P-H-P are seen in sequence to let us all know how it sucks by retreading the same old lines used by the last fifty guys who said the same thing but to your credit you really tried to be clever about it.

A good portion of why people like to mock PHP is due to the way people end up using the language rather than the language's ugly parts. This guide is a great step toward pointing people in the right direction with the language. PHP has come a very long way and continues to improve. A big chunk of the battle is having decent guides to replace all the crap that's out there showing new PHP devs the wrong way. So why not talk about the merits of the guide rather than taking an easy opportunity to shit on PHP. It's really gotten old.

Hey, remember when JavaScript was like the worst language ever and everyone felt the need to remind everyone about that constantly? I do. And now all of them are writing blogs about how awesome node.js is.

Post reply on HN