This is the first article of this blog and the author is going to record the most time-consuming part during the website construction.

LEMP (Linux, Ngnix, MySQL, and PHP) and LAMP (Linux, Apache, MySQL and PHP) are two most typical web stacks which WordPress is built on top of. This WebPress blog is built on top of LEMP stack. In order to make Nginx to interoperate with PHP, we need to include the following (or similar) lines in our site configuration file.

# /etc/nginx/<your_domain_name>
...
location ~ \.php$ {
  include snippets/fastcgi-php.conf;
  fastcgi_pass unix:/var/run/php/php<version_number>-fpm.sock;
}
...

Everything goes well until we upload a file larger than 2MiB to the blog. At the very beginning, Nginx will complain that the payload is too large to upload by responding with the error message "413 – Request Entity Too Large". But no worries, this can be easily fixed by adding another line to the website configuration file.

# /etc/nginx/<your_domain_name>
...
client_max_body_size 8M  # modify to any size that fits your need
...

Here, <your_domain_name> is your website's root. If we check the Nginx document, we will find that the default value for this entry is 1MiB. For the purpose of security, we just increase the max upload size a little above our need. Then we check the syntax of configuration file, and reload it.

$ sudo nginx -t
$ sudo systemctl reload nginx

At this point, Nginx stops complaining about anything, but we are not done yet. PHP claims that the file exceeds the max upload size for the site. If we go the dashboard of WebPress, then navigate to "Tools" -> "Site Health" -> "Info" -> "Server". We can see that the "upload max filesize" is just 2MiB. So, the next step is to increase this value. If you search around the Internet, you will most likely see lots of people tell you to modify upload_max_filesize and post_max_size in php.ini. As for locating php.ini, they suggest

$ php --ini | grep "Loaded Configuration File"
Loaded Configuration File:         /etc/php/<version_number>/cli/php.ini

If you follow this way, you will most likely get stuck here, because this is NOT the configuration file used by PHP-FPM, which is the PHP used by Nginx. Recall the configuration file we wrote above

# /etc/nginx/<your_domain_name>
...
location ~ \.php$ {
  include snippets/fastcgi-php.conf;
  fastcgi_pass unix:/var/run/php/php<version_number>-fpm.sock;
}
...

To verify our assumption, we need to create a phpinfo.php file under the website root to print out the debug information for us.

$ cd /var/www/<your_domain_name>
$ sudo vim phpinfo.php
$ sudo chown www-data:www-data phpinfo.php

The content of the file is fairly easy, which is just one line.

<?php phpinfo(); ?>

Heads up! There is NO white space between the first question mark and the keyword "php". Then we access this file through a browser by type in the URL, https://<your_domain_name>/phpinfo.php . It should tell you the location of loaded configuration file. In this case, it is /etc/php/<version_number>/fpm/php.ini , which is just what we expected before. After changing two corresponding fields we mentioned before, restarting Nginx and PHP, we finally found that we increased the max upload size to what we want. (Note: post_max_size should be at least as large as upload_max_filesize .) 

$ sudo vim /etc/php/<version_number>/fpm/php.ini
$ sudo systemctl restart php<version_number>-fpm
$ sudo systemctl restart nginx

The first lesson we learned here is that web development is quite different from system programming, where "debugging by printing" is discouraged because standard output's buffer will delay the moment when printing actually happens. However, in web development, "debugging by printing" has its unique advantage. The second lesson is that always be suspicious about what you hear and what you see from the Internet, especially when you get stuck for too long.