Summary of some excellent features of Codeigniter _ php instances

This article summarizes some excellent features of Codeigniter, which is my personal experience and is recommended to you. Recently, I was ready to take over and improve a project written by someone else using Codeigniter. Although I have used CI before, I did not follow the CI routines. For public projects, it is best to follow the framework specifications, so we should sum up, so that you do not have to smile when others take over again.

1. MVC

If you do not know MVC, you should learn it as soon as possible. You will soon experience the value of data access in the Model, business logic in the Controller, and HTML code in Views. If you haven't used this mode to write programs before, you may frown, but you should give yourself the chance to try it.

One practice principle is to put less things into the Controller. Remember the DRY principle: do not duplicate the wheel. When writing the same code in more than one place, you should try to write a library, helper, or model based on its type. For example, if the database connection class is frequently used, it is made into a model (provided by the system ).

Once you understand the essence of MVC, it will become a habit and you will benefit from the simple code of MVC.

One principle is that complicated operations are handed over to the Model. The Controller is more like an architect. Model is hard work. View is a fresh worker. The Controller only needs to throw things into the Model. It does not need to care whether the data is abnormal or not, and then returns a flag and corresponding data. In this way, the MVC Architecture is reflected.

The Model is actually like an electric appliance, such as a microwave oven. The simpler it is to use it, the more people like it. (put the food in and press start-OK to cook it .) The advantage of fewer interfaces is that the Model upgrade code is not highly coupled with the outside world. Even if you write poorly internally, the interface is clean and easy to use.

2. Application and System paths

It is best to place the system and application folders outside webroot, if the index. put php In the/public_html/path of the FTP server. Try to put the System in the root directory/system. In this case, you can only use index. php accesses your php file.

Do not forget to modify the values of $ system_folder and $ application_folder in the index. php file. The value of $ system_folder should be relative to the index. php file, and the value of $ application_folder is relative to the system directory.

3. Error Reporting and debugging

A common mistake is to forget to close PHP errors and database error reports. This is risky. In any public site, error_reporting should be set to 0 and can only be set to E_ERROR at most. db_debug should be set to false for database settings. Based on other security considerations, ini_set ('display _ errors ', 'off ');

When coding and debugging, you should set error_reporting to E_ALL, and resolve every note and warning before releasing the application.

A simple method is to set the db_debug value to a constant MP_DB_DEBUG in the application/config/database. php file. When the website is running, set the following:

The Code is as follows:

Ini_set ('display _ errors ', 'off ');
Error_reporting (0 );
Define ('mp _ DB_DEBUG ', false );

In encoding and debugging, set it:

The Code is as follows:

Ini_set ('display _ errors ', 'on ');
Error_reporting (E_ALL );
Define ('mp _ DB_DEBUG ', true );

4. Security issues are important

Whether it's POST data, COOKIE data, URI data, XML-RPC data, or data in the SERVER array before receiving any data to your program, we recommend that you perform the following three steps:

Filter bad data.
Verify the data to ensure that it meets the correct type, length, size, and so on (sometimes this step can replace step 1)
Convert the data before submitting it to your database.
For SQL injection, XSS, and CSRF, you should first understand them and then decide whether to adopt methods to prevent them. Refer to the security guide and input and security classes in the CI manual. Perhaps the most important principle is to check all user input before submitting data to a database or file system.

SQL Injection. Use the Active Record that comes with CI to solve this problem.
XSS (XSS ). By setting $ config ['Global _ xss_filtering '] = TRUE; Enable automatic filtering of cross-site scripting attacks in POST and COOKIE, but it consumes some resources. You can also set the second parameter to TRUE when processing the POST and COOKIE, for example, $ this-> input-> post ('some _ data', TRUE ); the Form Verification class also provides XSS filtering options, such as $ this-> form_validation-> set_rules ('username', 'username', 'trim | required | xss_clean ');
CSRF (Cross-Site Request Forgery ). CI 2.0 will be built into the CSRF check, search "CSRF tokens" on Google to learn