This is an excerpt from my book PHP for the Web. It's a book for people who want to learn to build web applications with PHP. It doesn't focus on PHP programming, but shows how PHP can be used to serve dynamic web pages. HTTP requests and responses, forms, cookies, and sessions. Use it all to build a CRUD interface and an authentication system for your very first web application.

Chapter 11: Error handling

As soon as we started using a PHP server to serve .php scripts in Chapter 2 we had to worry about errors and showing them in the browser. I mentioned back then that you need to make a distinction between the website as it is still running on your own computer and the website as it is running on a publicly accessible server. You may find that people talk about this distinction in different ways. When you're working on your website on your own computer you're running it "locally" or on your "development server". When it runs on a publicly accessible server it has been "deployed" to the "production server". We use different words here because these are different contexts or environments and there will be some differences in server configuration and behavior of the website depending on whether it runs locally or on the production server. In this chapter we'll improve the way our website handles errors and we'll make this dependent on the environment in which the website runs.

As a rather unusual pastime for the Saturday night I attended the third Domain-Driven Design Africa online meetup. Thomas Pierrain a.k.a. use case driven spoke about his adaptation of Hexagonal architecture. "It's not by the book," as he said, but it solves a lot of the issues he encountered over the years. I'll try to summarize his approach here, but I recommend watching the full talk as well.

You've picked a good refactoring goal. You are prepared to stop the project at anytime. Now how to determine the steps that lead to the goal?