See your errors before someone else does Often malicious hackers use debugging or error information to take advantage of a broken application. This is why it is critical that you perform extensive tests on your Web applications before you deploy it on production servers. The best way to test and find problems is to have all levels of error reporting enabled using the error_reporting(E_ALL) function. This function should be used as the very first line in your application code. For example: <?php // Enable all error reporting error_reporting(E_ALL) // Your code goes below. ?> During development you should set error_reporting() to E_ALL, which enables all types of errors to be reported. There are many error reporting levels. You can find all about these error reporting levels in http://www.php.net/manual/en/ ref.errorfunc.php#errorfunc.constants Once you have thoroughly tested your application, you can reduce the error reporting level or even disable it. However, if you do the latter, make sure you enable error logging using the error_log() function. You can learn about this function at http://www.php.net/manual/en/function.error-log.php. Restrict access to sensitive applications When you have an application that should be used by only a restricted set of users, you need to control access to the application from either PHP code or using Web server access control mechanism. This is covered in great detail in Chapter 22. Best Practices for Source Configuration Management When developing any software, use a version-control system to manage changes. We used Concurrent Version System (CVS) when developing applications discussed in this book. CVS allows you to create versions of your software by creating a source repository from which you check out and check in code changes. CVS main- tains all version information automatically so that you can retrieve an older Chapter 3: PHP Best Practices 61 05 549669 ch03.qxd 4/4/03 9:24 AM Page 61 version with a single command. It is also the de-facto version control mechanism for many large-scale Open Source software. You can learn more about CVS at www.gnu.org/software/cvs or at http://www.cvshome.org. Summary In this chapter I have discussed various best practices for functions/methods, data- base, user interface, documentation, security, and version control. Getting used to these best practices is often very difficult since many programmers are often under great time pressure to produce workable applications. However, it is very important to get started with these practices as early in the development as possible so that they become second nature in future projects. This is particularly true for getting used to version control tools such as CVS. Many developers find version control as an “additional task” that does not relate directly to the deadline and simply wait till the very end to place code in version control. This type of practices often leads to big code maintenance problem in the long run. The key issue is early adoption of best practices so that you get used to it from the beginning. 62 Part I: Designing PHP Applications 05 549669 ch03.qxd 4/4/03 9:24 AM Page 62 Developing Intranet Solutions CHAPTER 4 Architecture of an Intranet Application CHAPTER 5 Central Authentication System CHAPTER 6 Central User Management System CHAPTER 7 Intranet System CHAPTER 8 Intranet Simple Document Publisher CHAPTER 9 Intranet Contact Manager CHAPTER 10 Intranet Calendar Manager CHAPTER 11 Internet Resource Manager CHAPTER 12 Online Help System Part II 06 549669 PP02.qxd 4/4/03 9:24 AM Page 63 06 549669 PP02.qxd 4/4/03 9:24 AM Page 64 Chapter 4 Architecture of an Intranet Application INTRANET APPLICATIONS ARE PRIMARILY focused on automating an organization’s daily business processes. A modern company has many intranet applications that are available to its employees to help them be more productive and efficient. For example, a group calendar system or task-tracking system can save a great deal of time and resources for most companies with more than five employees. This chap- ter focuses on the underlying architecture of intranet applications and discusses an open-source framework that enables you to develop intranet PHP applications in a rapid manner. Understanding Intranet Requirements To develop intranet applications, you need to understand how a typical intranet is deployed. A company with two employees can have an intranet, but the average intranet application is deployed in an organization with tens to hundreds of users. Figure 4-1 shows how an intranet “connects” employees in multiple departments of a company that uses an intranet application server to manage its daily internal business functions. A company generally uses its intranet server to automate interdepartment com- munication activities such as a shared calendar, shared contact database, document management, project/task tracking, and so forth. Before you develop the framework that will enable you to create intranet appli- cations in PHP, you need to understand the intranet user requirements. Figure 4-2 shows how a single department within an organization appears from an intranet- requirements point of view. Users in organizations work in teams. A team usually has a team leader and a project assignment. The projects are managed by the department head. This type of hierarchical user base is very common in modern organizations. 65 07 549669 ch04.qxd 4/4/03 9:24 AM Page 65 . reporting levels. You can find all about these error reporting levels in http://www .php. net/manual/en/ ref.errorfunc .php# errorfunc.constants Once you have thoroughly tested your application, you can. using the error_log() function. You can learn about this function at http://www .php. net/manual/en/function.error-log .php. Restrict access to sensitive applications When you have an application that. This function should be used as the very first line in your application code. For example: < ?php // Enable all error reporting error_reporting(E_ALL) // Your code goes below. ?> During development