I have found myself time and time again having to configure the file upload limits of most webservers that I have worked on. And a lot of the time I have found it can get a bit confusing and frustrating to find where exactly it is being limited.
For standard PHP and Nginx set ups we need to look at the following settings:
In php.ini you will want to look for:
; Maximum allowed size for uploaded files.
upload_max_filesize = 40M
; Must be greater than or equal to upload_max_filesize
post_max_size = 40M
And for Nginx itself there is the client_max_body_size config variable that needs to be set.
However this is where it can get a bit messy if someone has configured this value previously. I spent a bit of time trying to figure out why this wasn’t working on my set up and discovered that it had been set at the highest level the http context section in /etc/nginx/nginx.conf
This meant that the values I was setting in the lower site specific configs were being ignored as the http block takes precedence over anything set in my site-enabled configs.
For reference, the order of context priorities are as follows:
Have you ever had an issue embedding a frame or iframe on your website? Problems like the content not being loaded or displayed at all?
In my case I came across this problem when trying to preview plugins in my WordPress panel.
If you checked the browser console log, you might have seen similar message to:
Load denied by X-Frame-Options: https://yourwebsite.here does not permit framing.
This error message is caused by the web server (in my case Nginx) sending a HTTP header ( X-Frame-Options ) that is telling your browser to not allow loading of embedded frame content. This is security measure to prevent attacks known as clickjacking.
A quick way to see which config file(s) might be setting this header option for Nginx is:
sudo grep -R "X-Frame-Options" /etc/nginx/
which will output the offending files if they exist.
In my case the solution was to simply modify a single value in one of my configs. I changed:
add_header X-Frame-Options DENY
add_header X-Frame-Options SAMEORIGIN
Saving the config edit and restarting Nginx was enough to resolve this issue for me. “SAMEORIGIN” tells the browser to allow loading content in frames as long as the source content is from the same origin as the parent page (current website).