Hot answers tagged

8

Craft rewrites the location of those files using a query string, which is what's causing nginx to lose track of them. Using the try_files directive should force nginx to find and serve them properly. location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ { try_files $uri /index.php?$query_string; expires 7d; add_header Pragma "public"; add_header Cache-...


7

Yii will check for the following server environment variables when determining if it’s an SSL request: HTTPS – should be set to “on”, “ON”, or “1”; or HTTP_X_FORWARDED_PROTO – should be set to “https” or “HTTPS” Apparently this is a common issue when running PHP on Nginx, since that HTTPS env variable is only an Apache convention. Here’s an article that ...


6

Putting aside Craft for a moment, it's not just Craft, you'll usually end up throwing more things on a web server as time goes by. If those scripts/apps are expecting an .htaccess file and you're using nginx, you have to do some extra work to get those rewrite rules or additional pieces of magic working. As someone who cut his teeth on Apache, I've swung ...


6

There is no "this over that" for Craft specifically. Your own statement "it depends" plays a big role. I would read this pretty extensive post on DigitalOcean "Apache vs Nginx: Practical Considerations" as a good start on what software to use. https://www.digitalocean.com/community/tutorials/apache-vs-nginx-practical-considerations For me personally this ...


5

You can simply create a 'robots.txt' file in your templates folder and populate it using twig (templates do not need to end in .twig). Not sure what you're trying to control exactly, but something like this should technically work. User-agent: * {% set entries = craft.entries.limit(null) %} {% for entry in entries %} Disallow: {{ entry.uri }} {% endfor ...


5

For HTTP the default port is 80 and for HTTPS it's 443, obviously. If port is omitted in the site URL, then the default one is used. If you want to use a different port, you must specify a different port in the URL. So, the logical conclusion is that the port must be present in the URL. When building URLs to entries, for example, the site URL is fetched to ...


5

Ok, I got it working with: nginx vhost config: location /en/ { try_files $uri $uri/ @enrewrites; } location /nl/ { try_files $uri $uri/ @nlrewrites; } location / { try_files $uri $uri/ @rewrites; } location @enrewrites { rewrite ^/en/(.*)$ /en/index.php?p=$1 last; } location @nlrewrites { rewrite ^/nl/(.*)$ /nl/index.php?p=$1 last; }...


4

The request for the craft font needs to be rewritten, since the actual file is (usually) outside of the public web root. Usually, this will be handled by the location block in your nginx configuration that rewrites requests to index.php. After you added the location block that adds the CORS header, though, all requests for font files are processed by this ...


4

The issue had something to do with PATH_INFO. Adding 'usePathInfo => true' in general.php fixed the issue. Here's the detailed explanation from Craft docs: https://craftcms.com/support/enable-path-info.


4

Try resetting the permissions of the storage folder: https://craftcms.com/docs/installing#step-2-set-the-permissions (It's possible that PHP was running with higher-than-default permissions in the previous setup, in which case everything may have worked even if you hadn't explicitly made the storage folder writable.)


4

First, I can positively confirm I have Craft running on two not hosted, local servers - one a Ubuntu 14.04 (well, Mint) installation, and one a Windows box using Uniserver. Not sure quite what you're reading - and I think you might be misinterpreting what you're reading - but just about every dev around here will have a local install they work on, one way ...


3

I'm not sure why you believe this is sub-optimal? You only have to set this once. I'm speculating here but since Craft makes no assumptions about your content, it stands to reason that it also makes no assumptions about how it should respond to a non-standard port unless you specify it—the key word there being non-standard. In addition, Craft uses the ...


3

It turns out this is an nginx problem. This post describes it: The troubling part of the nginx configuration looks like this location = /robots.txt { access_log off; log_not_found off; } What’s inside isn’t the problem. It’s pretty basic, whether found (access_log) or not (log_not_found) don’t log it ( off;). The problem is with ...


3

So I added the following lines to my nginx file and it all worked location ~* \.(?:jpg|jpeg|gif|png|ico|cur|gz|svg|svgz|mp4|ogg|ogv|webm|htc)$ { try_files $uri /index.php?$query_string; } location ~* \.(?:css|js)$ { try_files $uri /index.php?$query_string; }


3

Here is one: https://medium.com/good-dog/deploying-craft-cms-to-amazon-ec2-running-the-lemp-stack-using-mina-e2ad955138fa#.54s4y29co Disclaimer: I work for the company that published this.


3

Add this to your nginx server block: server { ... large_client_header_buffers 4 16k; ... } and restart nginx. The default is 8k. If you have a lot of headers, beefing that value up should resolve it otherwise you may want to play with client_header_buffer_size as well.


3

After some digging, there appear to be two ways that avoid hitting the admin and url query strings. The first, (and apparently better one, as 'if is evil' according to nginx) uses location handlers: # 301 Redirect for trailing slash location ~ ^([^.\?]*[^/])$ { try_files $uri @addslash; } # 301 Redirect for trailing slash location @addslash { return ...


2

An addition on this, probably for later versions of Craft than @brandonkelly's answer. You also need to be careful where Asset definitions are made in the CP - specifically, under Settings>Assets>Volumes>yourAssetsName. the default or practice at some point was to have urls of the form: @web/your/resource/path however, as of Craft 3.1, a red-lettered ...


2

$_SERVER['SERVER_NAME'] is a global server variable (not a craft variable) and should be available. I don't use nginx, so I can't comment on where the $_SERVER['SERVER_NAME'] comes from exactly — but a quick google search seems to explain things: Blockquote nginx – $_SERVER['SERVER_NAME'] is the first entry in the server_name directive. As far as multi-...


2

I fixed it by adding rewrite ^/index.php/(.*) /$1 permanent; to my server block. This will redirect all urls containing index.php and something after it to the contents after index.php. E.g. /index.php/about will be permanently redirected to /about. Google knows that if something is permanently redirected its the same content and will only index the ...


2

Nginx's setting client_max_body_size was set to its default value of 1M because it was not specified after provisioning the DO server with Laravel Forge. Weird thing is just that the user doesn't get any response. Solution: Set client_max_body_size to something higher or 0 in your Nginx config file.


2

To fix the "No Input File" in your Nginx config, you'll need something like this inside if your php location handler: try_files $uri $uri/ /index.php?$query_string; That will cause it to run the query through Craft (via index.php) if the .php file doesn't exist, which then allows Retour to handle it. You can see this works by hitting a random .php url ...


2

I've tried doing this with headers and cookies, but haven't had any luck yet. What I think is happening is that these things are set after the request is made. You are correct. fastcgi_cache is basically a switch, is it on or off. Your backend has no say in that because nginx doesn't look to the backend at all to figure out whether it should serve the ...


2

Nginx-Craft has an example setup that does this: https://github.com/nystudio107/nginx-craft/blob/master/sites-available/somedomain.com.conf#L60 # 301 Redirect URLs with trailing /'s as per https://webmasters.googleblog.com/2010/04/to-slash-or-not-to-slash.html rewrite ^/(.*)/$ /$1 permanent; This is working on the nystudio107.com site, if you go here: ...


2

IMO, the issue is with this line. SetEnv HTTP_ACCEPT text/html,application/xhtml+xml,application/xml,application/json;q=0.9,*/*;q=0.8 With ACCEPT headers set to a fixed value, it's impossible for Craft 3 to distinguish between Json and HTML requests. This must have been a necessity with the nginx proxy setup. I suggest removing this line from Apache and ...


2

The best way to accomplish what you're trying to accomplish would be to utilize the after.sh shell script that Homestead provides. Check out Extending Homestead and Local Development with Vagrant / Homestead


1

If you can't enforce sticky sessions, then you'll need to provide a common place for all load balanced web server to save their PHP session files. By default PHP session files are file based and saved to whatever path the php.ini session_save_path is set to. You could change that to an NFS share path. If you had an in-memory key=>value store (like Redis, ...


1

You might also need to add something like this for your actions pages: location ^~ /actions/users/setpassword { try_files $uri $uri/ @phpfpm_nocache; }


1

Craft install (LAMP) LAMP Install Step 1: Install Apache and Allow in Firewall apt-get update apt-get install apache2 Set Global ServerName to Suppress Syntax Warnings apache2ctl configtest nano /etc/apache2/apache2.conf ADD: ServerName 'server_domain_or_IP' apache2ctl configtest systemctl restart apache2 Adjust the Firewall to Allow Web Traffic ufw ...


Only top voted, non community-wiki answers of a minimum length are eligible