(Part 2) Best products from r/PHP

PHP5 and MySQL Bible

Never read it, but I'll review it anyway.

Good

• It's yellow.
  
  Bad
  
  
• It's also almost 8 years old now, so it predates all of the PHP good stuff.
  
• Programming books that look like phone books are usually lousy, especially if they have three or more authors.
  
  PHP and MySQL Web Development
  
  Read it, not a bad book.
  
  Good
  
  
• It's MySQL coverage is better than any of its contemporaries--it was one of the first intro texts to recommend using the mysqli extension instead of mysql
  
• It devotes four good chapters to security.
  
  Bad
  
  
• It's getting old. It was obviously written before PHP 5.3 and the rise of the Web frameworks.
  
• It definitely skimps on object-oriented design.
  
• Kind of phone-booky.
  
  PHP Objects, Patterns and Practice
  
  Own it. Great book, but--as mentioned elsewhere--not the best if you're a true newb.
  
  Good
  
  
• It's remarkably well-written. Zandstra is a good communicator and teacher.
  
• It object-oriented design, not just object-oriented programming. Most PHP books teach the small-scale mechanisms of OOP--how to make a class, how inheritance works--but PHP O,P&P teaches how assemble classes into an application. Patterns are introduced in the context of a problem. Different solutions to the problem (in the form of design patterns) are examined. The consequences of design solutions are weighed. It does a good job of explaining what makes applications well-designed (loose coupling, separation of concerns, flexibility, etc) and why we should care.
  
• It's fairly up-to-date, covering things like PDO and unit testing that are central to PHP development now.
  
• It is a real book, not a phone book. Apress books aren't big blocks of paper that occupy your reference shelf. They're meant to be read.
  
  Bad
  
  
• It isn't an introductory book. If you don't understand at least the basics of programming you won't be able to follow it. It's a great second book, but not a great first one.
  
• It doesn't thoroughly cover the "webby" or "databasey" side of PHP. It won't teach you about sessions or HTTP headers or parsing XML or any of that important stuff. The assumption is you already know. While there's a good chapter on database patterns, it assumes you already know enough about SQL to create and manipulate a well-designed, normalized database.
  
  For a true newb I'd recommend Beginning PHP 5.3 by Matt Doyle. It's a solid intro to modern PHP. Follow that with the Zandstra book or a good database book.

Ahead: I'll be saying unpopular things here. Please consider the actual points before downvoting and if you disagree, please do so with a post or upvote a reply that you think explains a disagreement with what i say best. Also please keep in mind that this is my perspective and opinion, i do not claim anything as fact.

***

I think the main problem with PHP is that, ultimately, it seems to be a language by lazy people, for lazy people. Now, this in itself is not the problem. Laziness is a virtue.

However it seems to encourage a certain type of mindset that results in developers caring less about good design, stability and security^1 than other developers would wish them to.

It also seems to lead to a certain kind of complacency. Since quite a few PHP developers will be of a certain lazy kind of sort, they won't seek out other languages to learn. I have known quite a few people who do PHP as their day job. I can group them into two kinds:

• ones that dislike PHP, and actually do know other languages with high familiarity
  
• ones that like PHP, but knew no or few other languages with high familiarity
  
  The result from that in my experience is that with PHP programmers in the second group i can have less meaningful conversations about generic programming topics because they've simply never worked with concepts that are not present in PHP itself, and on the other hand cannot meaningfully convey them new ideas, like the benefits of functional programming.
  
  Also, something people seem to like to ignore is that, while ultimately it is up to the developer whether they write bad code or not, the combination of target demographics in PHP and the lack of guidance towards good code by the core language do have an effect on how the average produced code turns out. (I hope i won't need to explain this, but can provide a more detailed example on request.)
  
  ***
  
  Personally I learned PHP as my 3rd programming language and used it successfully for 3 years. Then i switched to Perl and have been using it for 8 years with great success and pleasure. Looking back there are a few things that stand out the most to me in what Perl gave me over PHP:
  
  
• testing and quality compaigns. when i write a web app in Perl all the components run extensive test suites at installation and similarly all my code runs through integration test suite to make sure it all plays well together. this gives me a degree of confidence that PHP simply has not matched yet. similarly there is also nothing like Perl Best Practices for PHP
  
• scoping. with strict enabled Perl has very tight and clear-cut scoping, which means i need to remember less things at any given time. in PHP i need to wonder at all times if a variable came from before my current scope with a value already set.
  
• DRY culture. PHP has some sharing of pre-written components, and there is PEAR. however the amount and breadth of choice that CPAN offers isn't there, since PHP as a culture does not have this ingrained urge to identify and release components that can be generalized for reuse in other applications.
  
  These are the three main reasons why i personally prefer not to work with PHP.
  
  ***
  
  ^1 Compare: PHP - Perl

Hi mardix.

You were not down-voted because this is a toxic kindergarden where discussion is not allowed. You were down-voted because people did not like your idea - that is the point of Reddit.

If you disagree, you can down-vote. This lets you get a consensus of what people think of your ideas.

I can't speak for anyone else on why they didn't like your ideas, but here are my concerns:

1.) You are essentially side-lining new features which a lot of people are looking forward to seeing. Variadic functions and argument unpacking, use functions, and lots of other recent RFCs represent some great work which is moving PHP forwards as a language.

Calling this syntactic sugar is patronising and belittles the hard work being done by the RFC authors, namely /u/nikic who commented on your post, and got several up-votes for his fair points - which I will get to.

2.) You're assuming that everyone wants to use PSR-2. This leads to several sub-points.

a.) The reason PSR-2 exists was thanks to a decision to split it from PSR-1, as it was obviously controversial. This allows people to use PSR-1 (which is VERY useful) and ignore PSR-2 if they want to.
b.) Not all of the frameworks in the FIG want to use PSR-2, and I'm very happy they don't have to (as a member of the FIG myself).
c.) PSR-2 has currently not even been implemented correctly in CodeSniffer (read) due to some unfortunately vague wording. How could it be rolled into PHP perfectly?

More importantly than any of these points: why should it be rolled into the core? We can recommend it as a useful style guide to anyone who does not have a useful style guide, but forcing it down peoples throats does not benefit anyone.

3.) The job of language development is not purely about rolling things into the core. When I was a kid my dad used to read me this book called Mrs Armitage on Wheels. I can't remember it exactly and im not going to buy a copy, but she kept saying "What this bike really needs is..." and she'd add a sail to go faster. But then she couldnt stop so she added an anchor. But then it was too heavy and... bla bla bla.

Just shoving shit into a language doesn't make it better.

• If its working perfectly well out there in the eco-system, why shove it into the core?
  
• The reason these new tools are new is because they were built to fill a need. Needs change.
  
• PHPUnit is not the only unit-testing tool.
  
  4.) Your response to the reaction from the channel did not improve the situation because let me be clear: nobody gives a shit if you move to Python.
  
  5.) As nikic said:
  
  > Syntax changes go into core because that's the only place you can make them. That's not true for Composer and PHPUnit.
  
  They currently exist. They currently work. PHP The Right Way says they're good and you should look into using them. That seems like a pretty fair situation. Why go further?
  
  As you said:
  
  > We act like little kindergartners. We want, but we don't want.
  
  Unfortunately in this case you're acting like a kindergartener. People didn't agree with you so you're throwing your toys out of the pram and storming off in a sulk. You don't need to do that.
  
  I actually find Reddit to be an incredibly useful source of feedback. Every time I post something up here I get a HUGE range of responses. Sometimes its trolling, sometimes its truly bizarre but sometimes its amazingly constructive and new ideas come to light.
  
  None of that happened in this instance. You posted something that everyone thought was shit, and they reacted as I would expect them to.
  
  Edit: This also has literally nothing to do with ircmaxell's post, and it is demeaning to him and his valid concerns that you would draw a comparison to your suggestions that "rolling things into the core might be nice or something".

Hi! Sorry for the delay, I wanted to answer this correctly (and I'm happy to discuss it further).

> If anyone else than Symfony created a HTTP client, I would argue you wouldn't have answered with the same level of questioning.

Agreed.

> it means Symfony has a reach and people expect high quality packages coming from it.

Yes high quality is a criteria, but it's not the one thing. I think the key here is the impact: Symfony has a lot of weight in the community.

> But it's also a shame, because it tends to demotivate people trying to innovate. When everyone is asking you to justify every single action you do, you tend to stop because you're tired, especially if you do it for free.

Understood, sorry about that. I'll try to be careful about the way I say things.

The thing is that it's hard discussing some topics, and this is something I see often: either you say nothing (and avoid any risk to hurt or displease anyone, or even look like a fool), either you speak, but you need to find the right words and formulate it in a constructive way.

I want to speak about this topic because I care. And because most developers I am discussing with are unhappy as well (but none of them is saying much). I find it disheartening to see this (given how Symfony is important and used, and how many people work on it - including for free as you said), and my goal is to share this in the hopes that things change somehow. I am not looking to dismiss anyone's work.

Now let's try to discuss the actual topic:

I agree that it isn't just about Guzzle vs Symfony's new component, or even PSR-18 (which is why I don't think it's worth discussing specifically about this). A few facts:

• Symfony left the FIG, and before that wasn't really involved anymore for some time
  
• Symfony reimplemented some projects that existed and were used by the community (Guzzle is another example, but another example that comes to mind is DotEnv)
  
• Symfony Flex changes how Composer, the most standard thing in PHP, works
  
• Flex recipes are controlled by Symfony in a repository (whereas Composer is an open thing)
  
• the PHPUnit bridge highjacks PHPUnit's behavior (again, one of the most standard package in PHP)
  
• some new components are discussed "in private" and announced to the community, where it used to be discussed openly before
  
• (I'm stopping here because you get the point)
  
  Now I hope I portrayed these as facts (and I may have some of them wrong). I completely understand that many of these things happened because of good technical reasons.
  
  But if you look at it from what "it looks like": Symfony seems to be aiming to be a closed ecosystem. Symfony used to be the open framework, built upon reusable components and compatible with any PHP library out there. Now it feels like things are changing (note I am talking about a feeling, it may actually not be the case but that's what some people feel). For example some people believe that the next step for Symfony is to reimplement Monolog as a component (and possibly ditch PSR-3), and the next step would be Doctrine. Same goes for API Platform. Personally I think it's possible that this may happen.
  
  And things can change, it's fine, but here it seems like it's a whole change of identity. And I think that's why some people feel uncomfortable, and that's why as well it's so hard to voice (because it's intangible).
  
  Lately I've been reading Start with why and it explains it very well. Nobody complains about Laravel releasing stuff in a closed ecosystem: that's what Laravel is about. It's part of its identity. Symfony's identity has (from my perception) always been different: more open, more about the community, etc. Maybe it's time to redefine clearly the Symfony identify (and explain that it's changing)? Maybe it's just a communication issue? I don't think it's a technical issue in any case.
  
  Anyway as you can see it's not easy putting words on all of this. But to reiterate: I'm talking about how some people feel (to give concrete number it's between 5 to 10 people). And I feel like it's worth talking about it because I care about the Symfony and the PHP community. I hope that helps!

In my opinion, both PHP and Ruby can work well for this.

Were you to use PHP, I'd recommend a framework anyway, something along the lines of Laravel (my favorite at the moment).

This effectively gets you the same general framework tools that you would have using Ruby on Rails. I disagree that RoR would be "too much" for this project, it can be heavyweight, but it is that way to help you create your application faster, not because it has an over abundance of features.

The advantage of PHP is that there are a great deal more choices for hosting your project than with Ruby. That said, there are great choices for hosting Ruby as well - just not as many of them.

I would look at the two languages and get a sense of which you'd be more productive in off the bat. My guess is that would be PHP, because although more people are moving to using template engines like Twig, you can still mix PHP into HTML extremely easily In my opinion, that lets you experiment faster than you can with Ruby.

If you chose PHP, I'd recommend the PHP Cookbook http://www.amazon.com/gp/aw/d/0596101015 - it's a touch older now, but it contains very helpful learn-by-solving-a-problem recipes that can get you familiar with the basics of the language quickly.

If you're a more academic learner, you might try the more rote Programming PHP http://www.amazon.com/gp/aw/d/1449392776/ref=pd_aw_sims_2?pi=SL500_SY115 - which covers a lot more basics, but doesn't solve as many problems. Still, teaches a lot of the core language.

From there I'd work through tutorials on whatever framework you chose so you can get a sense of the patterns that framework uses. In conjunction with building your core knowledge of PHP, you'll start moving pretty quickly.

Sure, though I've also read people in your position are better at building apps with JS if they're new to it because things like PHP are completely different in how you start growing an app (classical vs prototypal inheritance) not to mention that if you also do PHP instead of just straight JS you're getting used to and learning 2 languages that are completely different in how you code. In either case you're right you have to learn JS anyway, here are the best resources after codeacademy basics stuff:

JavaScript: The Definitive Guide: Activate Your Web Pages (Definitive Guides):

http://www.amazon.com/JavaScript-Definitive-Guide-Activate-Guides/dp/0596805527/

JavaScript: The Good Parts:

http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742/

Programming JavaScript Applications: Robust Web Architecture with Node, HTML5, and Modern JS Libraries:

http://www.amazon.com/Programming-JavaScript-Applications-Architecture-Libraries/dp/1491950293/

A cool talk from last year of the Fluent conference (and the author of that last book) explaining how different something like PHP and JavaScript are and why JS doesn't deserve the bad rap it used to get (He's a pretty cool guy from Adobe and I got to talk to him last week about all of these things we're talking about right now and where web development is heading, and why JS as a single language for the web can work even better):

http://www.youtube.com/watch?v=lKCCZTUx0sI

This was a really cool overview on JS today, and you get to see Unreal Tournament and the Unreal 4 engine run in a web browser:

http://www.youtube.com/watch?v=aZqhRICne_M

The book Learning PHP, MySQL, JavaScript, CSS & HTML5 was one of the most useful PHP books I read as a newcomer to PHP. It's very basic but it teaches how you can start using PHP to do useful and interesting things.

After making it though that book, I think PHP Objects, Patterns, and Practice is a really good next step. It will help you learn to design, organize, and write your code to a more professional standard. It will also help you better understand the workings of a PHP framework.

This book helped me boost my PHP programming to a whole new level, hope it helps you as well. Also look into frameworks like Symfony or Laravel, they're definitely worth learning if you want to be serious about PHP

For PHP I would definately recommend PHP 5 Objects, Patterns and Practice. Pro PHP Refactoring is also pretty good. And the latest book on PHP Security is good too.

For javascript I would start with the Good Parts, go to Javascript Enlightenment and read what is available in EAP for Secrets of the Javascript Ninjas because although the book may never actually be finished what is there is worth 30 average javascript books.

These two books were the best programming books I have ever read:

• Code Complete (2nd Edition)
  
• The Pragmatic Programmer
  
  Code Complete is focused more around OOP, however both of these books will teach you how to become a better programmer.
  
  I recommend these timeless books for all programmers of any experience level.
  
  

Granted this was a long time ago (circa 2005) but I learned by reading PHP and MySQL Web Development. Cover still looks the same as it did back then: https://www.amazon.com/PHP-MySQL-Development-Developers-Library/dp/0321833899/ref=asc_df_0321833899/?tag=hyprod-20&linkCode=df0&hvadid=312125971120&hvpos=1o1&hvnetw=g&hvrand=16526201816409799004&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9008452&hvtargid=pla-434745475082&psc=1&tag=&ref=&adgrpid=61316180839&hvpone=&hvptwo=&hvadid=312125971120&hvpos=1o1&hvnetw=g&hvrand=16526201816409799004&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9008452&hvtargid=pla-434745475082

I got mine from the library. I'd browse your library for some books, check out a few, and see what works for you. I only ended up reading half the book. But for that half, I did all the exercises. From there I began building the ideas I had been dreaming of. Not a lot of good code in those early years, but thats part of learning. It definitely gave me a good basis. Before reading that I only had basic programming understanding like if statements and variables, didn't even understand loops or arrays.

I can't recommend your local library enough. Don't buy a book from Amazon or Barnes and Nobles that might just collect dust. If they don't have anything good then buy.

I'm new to php and somewhat new to programming as a whole. A friend pointed me towards Apress books and I ordered "PHP for absolute beginners" off of amazon. I haven't received it yet but I read/worked through the first couple chapters on kindle and it is very helpful and informative to a novice like me. The updated 2nd edition just came out in August of this year.

http://www.amazon.com/PHP-Absolute-Beginners-Jason-Lengstorf/dp/1430268158/ref=dp_ob_title_bk

Every quality software should have tests. So...

Read the unit tests / features tests first. Those will show you how a specific piece of the code works.

Also:

1. Play with composer packages.
   
2. Learn about PHP SPL
   
3. Learn about design patterns and beyond
   
4. Learn TDD, setup PHPUnit, Behat, Mink, PHPSpec
   
5. Read PHP The Right Way
   
6. Learn about clean code, EBI, DCI and how to put MVC on a shorter leash here: http://ikke.info/clean_code.html and here http://ikke.info/todo.txt and check out the #cleancode IRC channel on freenode
   
7. Read a couple of books like: PHP Objects, Patterns and Practice or Code Complete or Clean Code or The Pragmatic Programmer or The Mythical Man-Month
   
8. Start an open-source project or contribute to one
   
   
   There are a lot to learn and if you really like programming you will never stop learning.
   
   

• Michael Feathers - Working Effectively with Legacy Code - this book contains some helpful thoughts on how to write tests. This is important to know what you need to test rather than just stupidly cover lines of code without any profit.
  
• Kent Beck - Test Driven Development by example - to learn how to do this red-green-refactoring cycle.
  
• Robert Martin - Clean Code: A Handbook of Agile Software Craftsmanship - this book is more like "how to build your objects".
  
  Basicly TDD won't help if you don't think enough about how objects are interacting. Your tests are like client code for objects you are designing. They forces you to make more easy-to-use interfaces and think more about decomposition.

This one helped me hit the ground running: https://smile.amazon.com/Real-World-Developing-High-Quality-Frameworks-Applications-ebook/dp/B004XCRBMG?ie=UTF8&ref_=asap_bc#navbar

It talks a lot about code smells in general, as well as code best practices that lead to more testable code. Would recommend.

My only reservation here is that it's not really a TDD exercise. TDD typically involves choosing and writing tests for the functionality being added next by the developer, as opposed to here where the test dictates the next piece of functionality to add. It's a subtle difference, but a tangible one.

Now I'm not saying that this isn't a good idea. I'm not saying it isn't useful. Just that it's not quite TDD, as the design evolution is already in place for you, and you're just writing the code.

For a great example of what I'm talking about, check out Kent Beck's Test Driven Development, By Example. He walks through developing a few applications using TDD while keeping a "mini backlog" of what to do next, constantly adjusting the priorities.

Again, not putting this down, just not quite sure if it's as much as a TDD exercise as a testing exercise. But it's an interesting concept...

This thread, so far, includes only non-sequitur, off-topic, borderline defensive responses. Not that it's all bad advice; it's just mostly unrelated to your question.

There is value in learning how to analyze algorithms at a level beyond google-driven paging-in of topics when you need them. I'd propose that anybody telling you otherwise has never taken a proper algorithms course (or undertaken the self-study equivalent).

That said, I don't know what kind of shortcut you're looking for. You should probably try to work through a respected algorithms text, like this one:

• http://www.amazon.com/Introduction-Algorithms-3rd-Thomas-Cormen/dp/0262033844/ref=sr_1_1?ie=UTF8&qid=1419737752&sr=8-1&keywords=introduction+to+algorithms

For TDD it's more about theory, the logic and steps pass from programming language and tools freely. So you don't need a PHPUnit specific book.

The best TDD book I've read is https://www.amazon.de/Driven-Development-Example-Addison-Wesley-Signature/dp/0321146530/. Read that then start applying those processes to your development flow.

Hey, I briefed over some of the comments here, and while I feel a number of them are useful and necessary, I think you need an actual hard copy book to start with, rather than jumping right the hell into the manuals.

The book I started with, with absolute minimal programming experience (just some C++ classes in high school), is Larry Ullman's PHP book. I started on the second edition, and it was everything I needed to get started programming with PHP and making dynamic applications. It should cover basics of MySQL and top the book off with regular expressions, which are absolutely necessary to any serious web developer, and he makes everything feel very accessible.

After some months of that and programming, you would be ready to enhance your skills, and his follow up Advanced PHP book covers a lot of interesting and esoteric areas. It might be more than you need, but it does start off with some practical chapters in OOP and classes.

In-between the two, he wrote a MySQL and PHP combination book that sort of acts as a stepping stone between the beginner's book and the advanced book, and it might actually be the most you need to program in PHP, but I found the Advanced book handy to use, and the first book I linked you was my personal guide and reference for about a year and a half as I grew in my skill set.

I would recomment some books and then - practice!
Online classes are also good and you can benefit from the live interaction in them.
These two books have high ratings :


http://www.amazon.com/Programming-PHP-Kevin-Tatroe/dp/1449392776/ref=sr_1_4?ie=UTF8&qid=1412540290&sr=8-4&keywords=learning+php

and

http://www.amazon.com/PHP-MySQL-Beginners-Mark-Lassoff/dp/0990402010/ref=sr_1_6?ie=UTF8&qid=1412540290&sr=8-6&keywords=learning+php

I am currently reading this which has been OK so far.

I previously read this O'Reilly book which I found helpful. It does cover some stuff you already know but I found it handy when explaining things like sanitising and salting etc. Plus it goes about making a basic social site.

I recommend learning about Domain Models (Crafting Wicked Domain Models by Jimmy Bogard is highly recommended) and Domain-Driven Design (this Pluralsight course is the best introduction in my opinion).

Though the sample code in those videos is in C#, it should be straightforward to translate it into PHP. Watching those videos and reading books like Implementing Domain-Driven Design have taken my coding to a whole new level.

I think this one is pretty good,with segments like problem-solution-discussion.Here is a snippet

PHP: The Right Way is an excellent option.

Another one is PHP & MySQL (https://www.amazon.com/PHP-MySQL-Development-Developers-Library/dp/0321833899) It has just been updated to the 5th Edition.

Well, I generally don't buy PHP specific books, so this book doesn't really talk about PHP, however a lot of the design patterns can be transfered over. I thought it was a very good book: Design Patterns: Elements of Reusable Object-Oriented Software

Another one that's not completely about OOP, but is PHP :
Real-World Solutions for Developing High-Quality PHP Frameworks and Applications

Not PHP-specific, but I'd grab some used edition of the "CLRS book", nicknamed after the authors' initials.

Personally I just gloss over the "mathematically proving it's actually O(log(n))"-type bits in favor of the algorithm explanations.

Also, don't be afraid of the try { ... } catch (PDOException $e) { ... } code, if you are not used to it, it can seem a little intimidating. I avoided PDO for a long time as it was so different (and I knew how to properly use mysql functions correctly), but once they announced getting rid of mysql functions, I forced myself to get used to it, now it is second nature.

Heck, I'm just now forcing myself into switching to do most things in OOP (and I've been programming in PHP for 13 years). This was a great book for me http://www.amazon.com/PHP-Master-Write-Cutting-Edge/dp/0987090879 covers explaining OOP and other topics like PDO

Test, test and test. Read about TDD (https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530). Learn about the tools (phpUnit, phpSpec, behat) and start using them. You will find hard testing at the beginning, like everything, but later you won't want to work in without tests.
Apart of that, learn how the composer package manager works and don't do anything without it. Don't reinvent the wheel and use components that someone already invested a lot of hours in (auth, orm, microframeworks).
Think about your systems as a composition of pieces that work well together, without need of coupling to a specific framework.

No. And every fucking article about DDD in some php Framework should be hanged over running water then burnt and theirs ashes spread around the solar system.

Frameworks are just details in DDD. Your app may even be just a detail. What is your company making? What is your Core Domain on which you should assign your top people and resources? What is on the periphery and can be using software from outside?

DDD is more a way to organize your company and decide what to focus on. The architecture you get should come from analysing your domains, your contexts and change when your common knowledge about those get better.

Instead of reading these kind of blogs and applying cargo-cult php DDD read the red book.

In this order:

1. PHP for the World Wide Web
   
2. PHP 6 and MySQL 5
   
3. PHP Objects, Patterns, and Practice and/or PHP Object-Oriented Solutions
   
4. High Performance MySQL: Optimization, Backups, Replication, and More
   
5. Introduction to PHP PDO
   
6. Model-View-Controller MVC

PHP Cookbook is the book I would recommend. It has examples for almost everything.

A good book for PHP 5.3 is http://www.amazon.co.uk/Beginning-PHP-5-3-Wrox-Programmer/dp/0470413964

I can't remember if it covers outputting to PDF but once you've got the language and MySQL down doing that is only a Google away.

https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530

They are older books, but really changed my way of programming. Refactoring by Fowler and Test Driven Development by Beck.

https://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672
https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530

Feeling overwhelmed and confused can always be solved by breaking things into small enough problems and making enough tests to make sure that your assumptions match reality.

Frameworks can be confusing the way they hide details away from you. Remember though, that with open source, there is nothing to stop you from digging into the framework methods you are calling and see how they work. If you get stuck, sometimes looking at the source will tell you more than looking at the docs. Try multiple frameworks in multiple languages. Once you think you have an idea of the different parts required, try using a template library and an ORM library and write the rest of the code you need to make a basic custom framework.

If you want to see a more direct approach to web services, take a look at Go, where frameworks are almost discouraged. http://thenewstack.io/make-a-restful-json-api-go/