| SitePoint Sponsor |
Well, I got a job.
When you are just making websites at home for fun or for few bucks, you have little motivation to become more effective and competent programmer.
Pressure of deadlines and unexpected situations that you'll encounter will make you more flexible, you will realize that reinventing the wheel is pointless (that's why we have libraries and frameworks) and you will have more time to focus on quality of your application logic.
I just used it for many years and then got a job as a PHP programmer; now its in my blood.
Have a good day.
Hello,
The first thing I did was buy the book PHP & MySQL for dummies. I recommend that for starting out because it can be accessed anywhere, even if you're not near a computer. It has examples, and descriptions of the main functions, principles, and concepts you will be using through out your PHP programs.
After that I had a pretty good understanding of what PHP does, what PHP was mostly used for, and how to use it. From there I just started experimenting and reading PHP tutorials from http://www.pixel2life.com. Now, 10 years later there's very little I don't have experience with when it comes to PHP. I've created database handlers, template engines, CMS's, Frameworks, shopping carts, even tested out the socket functions of PHP and made a chat server.
In short the best way to really master PHP is to keep using it and creating problems and then solving them.
The best way I learn my PHP is by starting a small project and continually trying to improve it. I am many times pacing the sidewalks outside thinking of a better way to handle what I want to do, often times it's something very small that bothers me. It can be exciting, but sometimes if I wrestle with my mind too much even after looking at my references I consult someone more experienced than I without being a nag if possible (only a few questions), and that other perspective can really get the choo choo engine roaring.
Practice is the most important in my opinion. Collecting knowledge doesn't do me much good if I don't know how to make use of it. Seriously, start some small personal projects and you'll improve very fast.
I'm shocked how little I know after a few years of PHP, I may just be a slow learner too. But it just seems to never end what you can learn and improve on, and I do write and read about PHP all the time, sometimes 5 extra hours a day in my free time. This is my first language though, I don't have a C/VB background so all these concepts are new to me like Patterns and Objects.
First of all, I want to precede my post by dittoing this comment.Originally Posted by Salathe
I'll tell you when I get there.
I'm still far from what I'd call competent. Fact is, most of the people that have already replied are much more competent than I.
That said...
If it weren't for this mindset I'd have NEVER even begun to actually learn PHP.
I've been involved in various aspects of web development (from graphic design, to front-end development, to project management, to content writing or even SEO) for over half a decade, as many here already know.
I've not received any formal education on the subect. (I'm a second-year business major dropout) Like so many here on SitePoint I've learned all of my skills through self-teach methods or from networking with other developers.
I spent years making small modifications to existing scripts, reading low-level tutorials, reading books and even watching videos. None of this did me any real justice. For me, PHP seemed to be a topic that constantly evaded me despite any amount of study.
It wasn't until a few months ago that a few of my friends (will come back to this) gave me the courage and confidence I needed to "take the dive" that wackyjoe is describing. Through the help and encouragement of these friends I began writing applications from the ground-up with little idea how to actually implement at the start. I tried to limit my use of tutorials and resources (as described below by Jake) to the following three things:
- Manual: PHP.net
- Book: Essential PHP Security
- Friends: Developers that I trust the advice of.
In the end, it was this dive that enabled me to wrap my head around the larger and more difficult concepts within PHP. (Some of which I am still working on) I mean, tutorials (and so on) gave me a basic understanding of the fundamentals of PHP. (variables, functions, arrays, operators, etc.) I don't believe I would never have come to understand the more advanced PHP topics (application design, OOP, MVC, Security, PDO, etc.) if it weren't for me taking this dive.
It's obvious from what I've written above that I agree. I think you're right in your second paragraph about the first being black and white, though. Tutorials ARE important for true beginners. The basics (variables, operators, etc.) can be learned from a tutorial successfully without instilling too much bad practice. Even the www.tizag.com PHP tutorial isn't perfect, but it does give you the toolset you need to begin practicing and understanding the more advanced topics.
I think your point about learning theory rather than code-specific solutions is a great one. I tend to lean in this direction as my implementation of the same theory may not be the same as the tutorial writer's implementation. I also believe this allows for less bad-practices to be instilled upon you.
This is a very important piece of the puzzle, or is for me at least. I've found that having friends that share your interest in PHP has been imperative to my success. I can't count the times a friend (often a friend that I've never even met in real life) has saved my rear end or taught me something critical that alone would have been completely overlooked. I can't tell you the amount of things I'd have never had the courage to try without the encouragement of these same friends. I can't count the times I've been taught the right way to something by these friends.
To be fair, I should give credit where credit is due. To the users of SitePoint these friends (not all of them PHP related) would be known as: deathshadow60, Dan Shulz, Jake Arkinstall, Paul O'B, ScallioXTX, felgall and so many more. (I do apologize for those I've forgotten)
All in all, I agree with many of the points made in this discussion but I would have never made it far enough to consider them without the help of my friends. For this reason, I consider it to be a very important piece of learning any technology.
In conclusion, the most important pieces of learning PHP (or any web dev technology, for that matter) for me were "taking the dive" and finding friends with similar interests. For any beginning PHP programmer, I would consider these the starting points. That said, I'm still a beginner myself!
— Alex Stanford @alexstanford tumblog about.me in fb G+ K
TechTalkin — The Premier Community for Technology Enthusiasts and Professionals
Full Ambit Media — Zero Sacrifice Web Design & Development; Made in the USA @fullambit in fb G+ K
practicing, much. i never read any book of any language, and i know C/C++, Scheme, Perl, Java, JS,CSS,PHP,XML,AS,PROLOG,ASM, and i think that's all.
Thanks to alex for reminding me - I forgot about this thread(Parkinsonism, fun stuff)
He is right about the friends thing too - the more people you knock ideas off of the cleaner/better the resulting code can be. We don't all think exactly the same, so getting a fresh perspective always helps... and for us older developers, don't ignore the new kids assuming you know everything - Alex is barely a month into learning PHP, and some of his ideas and fresh perspective made me pitch half the codebase of my "major WIP" CMS in favor of a entirely different structure and way of building the page.
... and lands sake don't be afraid to throw it all out and start over if it's going to be faster to write from scratch than it is to magic bullet fix some garbage tossed together from hundreds of K of libraries. That goes not just for PHP, but for Javascript as well. (I see one more site using 200k of javascript on a page with only 2k of content, I'm going on a killing spree)
I actually would agree with that wholeheartedly - if we were talking a compiled language - but we're not. We're talking about an interpreted scripting language, making EVERY dynamic include suspect...
Look at the exploits of the past decade - heck, look at the past three years. SMF's little avatar vulnerability could have been avoided by any one of a dozen things along the way... Not leaving files (like settings.php) 775 is just the tip of the iceberg when they trusted $_POST arrays (aka name="this[index1]") to actually contain the proper indexes and just dumps them to the user profile blindly, to having everything global for the connection info so once they got an attached avatar to run as code, it had full access to EVERYTHING.
Any one of a dozen different things could have stopped such an exploit - in a Forum software that's actually fairly well known for being more secure than the alternatives... and yet good practices went by the wayside with 1.1.6
... and SMF has one of the BETTER track records. Look at the total train wrecks like "2008 - the year of wordpress vulnerabilites" where they won the pwnie for m4ss 0wnage... or phpBB2 which I never understood how anyone could even consider that real world deployable just since it was so open to attack... Of course most of phpBB2's problems stemmed from it not doing ANYTHING out of box and needing to be so heavily modded there was no upgrade path -- nevernosanity (aka Santy) anyone?
... and 99% of these attacks could be prevented by following some simple rules.
1) Never put security information in globals or defines. This goes for your database connection too which is why the mySQL_ functions should fall into disuse in favor of PDO. (besides with constructed queries auto-sanitizing variables it's a no-brainer to switch). Also, local variables and restricted scope are your friend. (and what I wouldn't give for predeclaration and strict typecasting)
2) Never have library files that should never be called directly output anything if you do call them direct. It's called functions - USE THEM.
3) When auto-generating an include - like say the path to your theme, sanitize the input not just for code injection, but also for PATH injections. I'm amazed how often I see the ball dropped on that one.
4) ALL user input is suspect, don't assume that the fields you get back from the form actually have anything to do with your data structure.
5) It is better to have a single central script acting as your traffic cop than it is to allow each and every subfunction to have it's own script. That makes one central point at which you can handle security instead of the lather-rinse-repeat vulnerabilities and redundant code inherent in having a separate post.php, reply.php, boardlist.php, etc, etc, etc...
These are simple basic security rules going back almost two decades of interpreted/scripting languages -- and it seems like most major php scripts out there have forgotten or never learned them... Like Wordpress where the above concepts may as well be written in Aramaic. It really earned that pwnie, and for all the improvements in 2.8/newer, it's still a train wreck waiting to happen.
You mentioned it seeming like overkill? I'm reminded of something a co-worker told me when we were making a clipper based program that was going to be remotely accessed over dialup told be about security. "If it feels like overkill, it's probably still not secure enough."
Correction: Barely a month in REALLY learning PHP. As I explained, I've been fuddling with the basics for years but as for actually learning write applications from the ground-up? I'm just over a month into that. (And almost 3 applications in...)
I'm glad I can be of help. It's nice to know that the new guy isn't always a nuisance but that the benefit can be two-fold.
Great advice. Thanks to you I'm now recoding the front-end of my current project for the FOURTH time. It might sound like a bad thing, but it's not. It can be frustrating to start over at times, but in the end it's much less frustrating when your published product performs properly. (did I just make an accidental tongue twister, or what?)
rofl.
I'd prefer you didn't... but if you must... do let me know so that I can come with you.
I do ask that we target the people who actually defends such ideas, though.(edit: re-reading, I think we would more appropriately call this our "target audience"
— Alex Stanford @alexstanford tumblog about.me in fb G+ K
TechTalkin — The Premier Community for Technology Enthusiasts and Professionals
Full Ambit Media — Zero Sacrifice Web Design & Development; Made in the USA @fullambit in fb G+ K
@DeathShadow - those security issues are all simply poor design. A user-information sanitising layer would save the need for the running around in circles.
I'll put it this way - do you wrap your gold bricks each into their own custom-designed safe, or do you put them all into one safe which is impossible to get around?
A recent side-project that I'm considering involves a multi-layered framework. The MAIN framework executes blindly. You tell it to delete its own files, and it will.
The second layer controls what the base layer does. This simply restricts things to a certain extent. This means that if someone who sincerely just wants to USE the thing will be able to. This means that mistakes and accidents are generally caught.
The third layer is the outside layer - this is what the request actually uses. EVERY user input is tripple-checked, verified and stripped to the bare parts. Numbers are cast to numbers, any template files to be used are compared to the filesystem and verified for issues.
Because of the existence of that final layer, you can code the inner workings of the system without needing to worry constantly about the intentions of a malicious user - a load off your mind, allowing you to focus more and get on with stuff at a faster rate!
Jake Arkinstall
"Sometimes you don't need to reinvent the wheel;
Sometimes its enough to make that wheel more rounded"-Molona
I can relate to this because I'm in a very similar boat with PHP being my first programming language. Starting a small personal project has been imperative to my success as well and is great advice. I didn't want to let this go unmentioned after all I've said previously in this thread. This could be considered part of "taking the dive" as described earlier in the thread. I'd say it's the easiest and most logical way to "take the dive," if you will.
That really sums it up for me. I believe that's the reasoning behind all my above points.
I believe this is the reason that most beginners have trouble. Most of the resources are only going to make practical and usable sense to you if you're already familiar with the theory behind it. This is why I think it's such great advice to "take the plunge" and skip any unnecessary studies in regard to PHP. This enables you to get a feel of how it really works, how the theories are implemented and so forth. After you've been able to integrate something in ANY way the resources will make much more sense.
That said, some basic resources (like an introduction, friends and the PHP manual, as described above) are necessary throughout.
— Alex Stanford @alexstanford tumblog about.me in fb G+ K
TechTalkin — The Premier Community for Technology Enthusiasts and Professionals
Full Ambit Media — Zero Sacrifice Web Design & Development; Made in the USA @fullambit in fb G+ K
Kind of my point - they're things that should be done by default because you inherently can't trust an interpreted scripting language to even handle this stuff properly. It is poor design, and it's disgusting to see so many major scripts out there practicing it. Again, see wordpress.
... and yet all it takes is one mistake for the entire thing to fall apart when any number of checks along the way could have handled it.
Unfortunately most practical php scripts are broken up into sub-files... unless you are putting your entire application into just ONE single PHP file with no includes, your analogy kinda falls apart.
One bad upload (if the user is allowed uploads) or one exploit you didn't expect, and your single layer security falls apart.
"Every decent punk has a bulletproof door. But people forget walls are just plaster. Hopefully you get him with the first shot... or the second... Now he's down and waiting for you to come through the front door. So you don't come through the front door." -- Micheal Westen
... and yet what do you have in place SHOULD something slip through your sanitization you didn't expect (and yes, it's going to happen sooner or later) - what do you have to prevent that first layer from being called directly bypassing all your security.
That was something that plagued wordpress and still plagues it. All I need to do is find a single privilege hole and poof, I've got access to everything. It's as you said "poorly designed" because in 90%+ of the sub php files even have stuff wrapped in functions. (but then I believe well coded php files should start with <?php and end with ?> and only EVER have one instance of each in them!
Oddly, that's why I use prepared queries in PDO, why I wrap everything in functions, and pass my PDO object by reference to what should have access - the inner workings just knows "I'm a function that takes &$db and &$data as parameters". Inside those, it's much like your first layer, but because they're in functions working with locals instead of globals, it's a lot harder to compromise should the outer security layer fail. (like it always does in most every commercial script)
Its' not even any extra code or thought to implement those features, and it gives you multiple layers of security and fallbacks instead of the half-assed "gee I hope nobody breaks through the top level and isn't smart enough to call my subfiles directly"
Also makes it nice when working with PDO so you can pass your queries as local strings too - since I'm using all prepared queries and putting all the appropriate queries for the current function in one big array makes it easy to adjust them for the nuances and quirks of other SQL languages much like using a $text array on the output side for multi-language.
Deathshadow: You should really stop writing about security, because I'm a security professional who codes a great deal of PHP, and I can't grok 90% of what you're saying. Not because it's over my head or I don't understand best practice, but because you're incomprehensible.
I can see the nuggets of truth in what you're trying to post, but the way that you lay out information assumes that everyone who's reading your post thinks exactly like you do, and makes the same logical and rhetorical leaps that you do. This leads to a situation where someone inexperienced could end up thinking that something which is perfectly fine is completely inappropriate based of your single post.
Sorry to be so blunt, but you're being proven wrong (or illogical) in almost every thread you post in.
Funny, I say that about most so called "experts" in the field who seem to have forgotten most of the lessons of the past THIRTY YEARS.
But then, I started out in Assembly, so I understand how this stuff works under the hood, which makes me draw VERY different conclusions from people who've only ever been hand-held by a high level language.
I see a whole lot of assumptions going on there Jake, I fear your complete trust upon these layers of yours maybe your undoing.
What if, if, a request filters down to this 'blind' layer? Impossible you say?
@AnthonySterling: I'm a PHP developer, a consultant for oopnorth.com and the organiser of @phpne, a PHP User Group covering the North-East of England.
Or as I was saying, what precautions do you have to prevent those lower layers from being called directly or ******** with values.What if, if, a request filters down to this 'blind' layer? Impossible you say?
Admittedly, "the only secure system is one with zero access, from there it's a matter of degree" - but that doesn't mean that basic security concepts dating back three decades should be ignored.
... and "not storing security info in global variables" and "wrap EVERYTHING in functions" (or objects) is bare minimums - we're talking stuff I learned in high school in the 80's.
If it's written correctly, yes!
Quite simply, every request would filter down these layers, even those from within the application itself (i.e. when the application delegates a command through a sub-application, it must also go through these security layers). It wouldn't be possible for anything to pass through the system because it'd work with a pessimistic checking system - i.e. it only allows whitelisted commands rather than allowing everything other than blacklisted commands.
I suppose another way of putting it is that the upper layer has no access to the lower layer apart from through the middle layer. For example, just because you can request a page from your browser doesn't mean that you can change that page on the server - HTTP doesn't work like that. Well here the top layer is the metaphorical browser.
Of course, the integrity of the system would depend on the end-programmer's understanding of the system. The simplest approach is possibly to make as many helper functions as possible in the main bulk of the framework so that the programmer would find bypassing layers more of a pain than otherwise.
Of course, every framework can be bypassed if it has an idiot using it.
Unless you have inspected the entire PHP library (written in C) and understand the entire machine-level workings of C - and how HTTP requests work at the lower levels - 30 years programming (which I think we're all fed up of hearing about) and assembly knowledge don't do much to help you. I'm not questioning your knowledge, but sometimes secure is secure - it isn't impossible (or necessarily hard) to build a bullet-proof PHP application, you've just got to take care.Funny, I say that about most so called "experts" in the field who seem to have forgotten most of the lessons of the past THIRTY YEARS.
But then, I started out in Assembly, so I understand how this stuff works under the hood, which makes me draw VERY different conclusions from people who've only ever been hand-held by a high level language.
I think you need to, if you haven't already, realise that your way of doing things is simply that - your way of doing things! It has its downfalls and it also has its benefits, but sometimes your tone can be condescending. The OP asked about how to become competent in PHP and you start lecturing on about stuff that would go over a beginner's head.
Please try and keep things on topic, focussed and more about the original poster's experience. Of course I won't use my badge to allow myself to pose a point and then end the debate before allowing a response, so I'll give you one post to finish things up.
As for everyone else - same applies! We've gone way off topic here and it's starting to turn into a bit of an argument here. As we've seen many times before now, sometimes there is no 'right' way - if we all programmed to each other's standards then there wouldn't be any point in us being here.
Keep it clean and be friendly!
(Or else
)
Jake Arkinstall
"Sometimes you don't need to reinvent the wheel;
Sometimes its enough to make that wheel more rounded"-Molona
That's not a rebuttal, it's an appeal to (your own) authority and a deflection of my primary point, which was that if you are going to make a point, you should back it up. This isn't Schneier on Security -- you shouldn't make the assumption that your audience is inherently knowledgeable about the security landscape.
To use an example: you say that developers should never use global variables to store security state, and that's good advice (so is "Don't use global variables"). However, simply following a pronounced edict like that isn't how we get better software; indeed that path leads to Cargo-Cult developers following suggestions for the wrong reasons (and thus never knowing when they should break the rules they were given).
I can tell that you've got a lot of useful wisdom to impart to the community, but your communication style can make it very difficult to understand.
If your looking on open source projects and hope to see good/secure code then you will in most cases become utterly disappointed.
In general most open source PHP projects is plagued with security holes, mostly due to the projects started out of the code of a simple script written by someone and then afterwards its been modified/updated by more people that calls themselves PHP developers.
The ease of entry point PHP has is both a good thing and a curse. But it does cause the language to have a lot more bad developers than many other languages.
Btw, on the opening and ending PHP tags, if the PHP code is the last information in the document you can ignore the ending PHP tag.
Why would you be passing the PDO object by reference? Would it not be a better idea to wrap an adapter around it, as it would give you more options in the end.
Though claiming that every commercial script is like a swiss cheese is kind of a huge over statement. For a real commercial PHP script that has been created by a company, then there is usually not any more security issues than with any other software written in other languages (Thinking on application sold for $1000 or higher for a license).
On the other hand if you buy a license for an application that cost $50 you cant really expect that high quality.
Something does not sound too good here, thinking from an efficient application point of view. Sounds like there is too much information inside a few files making it too thigh coupled, this will make it very difficult to modify things later on.
Keep in mind that no chain is stronger than the weakest link. It does not matter if your script is as secure as "fort knox" if the backdoor is left unlocked (i.e. server).
Security is a good thing and way too many PHP developers look too lightly on it, but I believe that you are taking the security a step too far, by default you need to be able to trust the owner of the server. I.e. that any files they append to the script will be safe and not a security risk. The only main consern should be any data that is used by the script, as long as you make certain it is clean your application will be secure. If the server owner screws up and upload some unsecure files, then that is their fault, not yours as the author of the application. After all, if I have server access I can do anything I want anyway and your security approach on the PHP side wont help.
In addition your posts are a little incomprehensive and difficult to follow, so this might actually mean we get a different understanding of your post than the point you tried to get a cross.
If you have never read a book on any of the languages that you have learned then how have you got passed or through that "getting started" phase?
Using PHP as an example, did you go through tuts, or avoid that too, did you literally make a decision then search through the manual, which seems impossible to me to go from not knowing to just finding parts of the php language that just fit together.
I read of various approaches that people use to learn php, i was recently going through some books that i realised are not teaching how to build something but instead just explaining what the php manual explains but in more detail, ive recently though narrowed down a few books that look like they actually show how to build something.
I realise that having an understanding of some languages can make it a bit easier to learn another, but for someone like myself, new to programming, its like trying to learn japanese.
Im not suggesting that you should needed to have read any books on those languages btw.
Come on fellas, lets reign this in somewhat and keep the thinly veiled insults to ourselves.
It would certainly be a shame to detract from the excellent points many of you are raising, wouldn't it?
Thanks!
@AnthonySterling: I'm a PHP developer, a consultant for oopnorth.com and the organiser of @phpne, a PHP User Group covering the North-East of England.
Off Topic:
Anthony's a weener...
Thanks guys, that was great. Good answers to my ORIGINAL question.
Please stop bickering though....
First off -- THANK YOU!!! I've been saying that pretty much since the Church of Stallman was formed and am honest to JHVH shocked to find anyone else willing to actually SAY IT.
Also true.
Shades of Basic in most every incarnation. VB crapplets for example.
Yeah, but to me that's like leaving out the closing tags or WORSE, HEAD/BODY tags in HTML, I like to see it so that structure is maintained.
Because I don't want it to be able to be modified once initialized inside my db.php. I consider that another vulnerability. Much less that if I don't restrict it's scope by passing by reference, it's a global again.
I've seen sight few that qualify for that though - I'm not saying they don't exist, but there are very few that seem to meet up to that standard... Mind you, I've been dealing with garbage like Goldmine and so forth so...
Actually, makes it simpler in a way, though really it's a sacrifice to go cross-SQL. mySQL doesn't take the exact same queries as Oracle or MSSQL - hell there are even enough differences for postGre to occasionally need query tweaks. Do you inline those changes with if statements on every query, or do you just include the appropriate values by extending the PDO object with an array containing all your queries appropriate to the task at hand? This part of why I LIKE pdo->prepare a LOT.
As I said, the only secure system is one with zero access, from there it's a matter of degree.
It's sad when that's a step too far - really is.
Which is fine for large companies handling it in-house, but not for something joe-six pack is going to install on any of the billion fly-by-night shared hosts. I think the target audience plays a crucial role on that.
I've gotten that for 40 years, getting a little sick of it. As I've said other places "Englisc, modor wyrter! Gedon eow cweþan hit!?!" -- I know my manner of speech is archaic, but DAMN is education really that piss poor now or something? Half the time you make a simile now you get some jackass saying "That's off topic, what's that got to do with it?"... and yes, I said simile, not Smiley.
The lack of general literacy really is one of my pet peeves. Maybe I should just turn my hat around backwards, put my pants around my knees and start typing everything in L33T?
Though I also think it's the New England Yankee businessman attitude - we'll tell you something sucks to your face... and then try to help make it better. If you aren't willing able to get angry over something sucking, and couch every statement in meaningless plattitudes how the devil is anything supposed to get better. Slapping the rose coloured glasses on people's heads and leading them down the garden path by saying "everything's ok" is not how things get BETTER... But we're the type of people who will call you a lazy sleazeball *** to your face right before we give you the shirt off our backs.
New Englanders are NOT a friendly people in terms of speech - but we're also generous to a fault. <brooklyn>Ya got a freaking problem with that?</brooklyn>
"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw
Lawlz, yes.Maybe I should just turn my hat around backwards, put my pants around my knees and start typing everything in L33T?
You also need to add ", yo." to the ends of your sentences. Like this:
Shades of Basic in most every incarnation, yo. VB crapplets for example.
And you should try to shorten all your words.
n u shud try to short ur wrds, yo!
But seriously, to become competent at PHP, practice practice practice.
Challenge yourself, and if someone tells you you're doing something wrong, or that there's a better way of doing something, be glad for their help.
*Hup Holland!*
Posting Permissions
Bookmarks