Jump to content

Nginx Rewrite rules for IPB 3.0


ssslippy
 Share

Recommended Posts

I don't think we plan on supporting natively anything other than Apache mod_rewrite.

If a user wants to convert the .htaccess mod_rewrite rules for nginx (or any other rewrite software) and post them for us, we'll probably compile a KB entry with the info. Only the equivalent to the .htaccess rewrite rules would need to be converted.

Link to comment
Share on other sites

  • 6 months later...

i'd like to hook in here. Why not officially support nginx? Nginx is the most attractive Webserver currently, especially for sites taking more than the basic 1000 visits a day. More and more software products support or even recommend nginx. It would be great to see IP.* in this line.

Nevertheless: Probably anyone around already collected experiences with nginx and ip.board?

Link to comment
Share on other sites


We have customers using nginx. There's nothing on our end we need to do to "support" it. :)



I'd tend to think a webserver that you need to code for specially wouldn't be all that useful, unless everyone coded for it...




Hmmm... Is there anything special that has to be done in order to get IPB working on nginx? Except mod_rewrite... :) I mean is the switch to nginx simple as just instlling nginx and that's it? Or something else need's to be done? :)
Link to comment
Share on other sites

As far as I know, not taking into account any mod_rewrite functionality, yes. You just put the IPB stuff on an nginx webserver and that's it. You naturally need to have php and all the required php extensions, but we do not use server-specific extensions within IPB so you shouldn't have any problems there.

FURLs can work out of the box on nginx, without mod_rewrite, by putting /index.php/ in the URL (i.e. forums.invisionpower.com/index.php/topic/123-something). You can alternatively convert the mod rewrite rules to nginx within it's config file, and then enable the .htaccess setting in IPB's ACP (you won't really have a .htaccess file, but this tells IPB not to add /index.php/ to the URL) as well, if you are familiar with nginx and it's mod_rewrite syntax.

Link to comment
Share on other sites

Ok, so all i need to do is just install some other webserver and everything will work. That's what i want. :) Ill test this soon with nginx and lighttpd and hopefully the only problem will be converting mod_rewrite. ;) If everything works out ill just start new topic about that mod_rewrite on different web servers.

Link to comment
Share on other sites

  • 3 weeks later...

For those of you still looking for this....
here's a thread regarding this here: http://nginxforums.com/index.php/topic,187.0.html

here's what you'd need to add to your config file it looks like:

location /pathtoforums/ {
index index.php index.htm index.html;
try_files $uri $uri/ /pathtoforums/index.php?q=$uri;
}

location /pathtoforums {
index index.php index.htm index.html;
try_files $uri $uri/ /pathtoforums/index.php?q=$uri;
}


Not too sure if this is the same thing as what mod_rewrite would do, but it seems to work great for me.

Link to comment
Share on other sites

  • 2 years later...
  • 1 month later...

Just managed to get this set up myself after quite some time. It's pretty annoying that there's no official resource for this because Nginx is becoming increasingly popular and I suspect the majority of people don't bother to post their solution once they finally decipher the conflicting methods out there and get it working.

So, here's what worked for me:


server {

	 server_name www.whatever.com;

	 access_log off;

	 root /var/www/www.whatever.com/public_html;

	 location / {

			 try_files $uri $uri/ /index.php?q=$uri&$args;

	 }

	 location ~ .php$ {

			 include /etc/nginx/fastcgi_params;

			 fastcgi_pass 127.0.0.1:9000;

			 fastcgi_index index.php;

			 fastcgi_param SCRIPT_FILENAME /var/www/www.whatever.com/public_html$fastcgi_script_name;

	 }

}

The only bit I actually added was this:


location / {

        try_files $uri $uri/ /index.php?q=$uri&$args;

}

If I were running in a subdomain it'd be more like this:


location /somesubdomain/ {

        try_files $uri $uri/ /somesubdomain/index.php?q=$uri&$args;

}


location /somesubdomain {

        try_files $uri $uri/ /somesubdomain/index.php?q=$uri&$args;

}



I noticed the poster above said the solution posted earlier in this thread didn't work properly for pagination. That is most likely because that solution doesn't include the $args part, which presumably carries information like. And of course, in addition to all this make sure you have the FURL options enabled in your admin area and tell IP.Board to use a HTACCESS.

Link to comment
Share on other sites

  • 2 months later...

After much turmoil I have managed it on my own server.

I hope to make this an informative post governing some of the pitfalls I came across when setting up my sites-available file.

Firstly:

Here is my completed config file. Some was set up by a previous admin who had more experience with nginx than me. I had to modify his default file when I moved my forums. I'll explain the parts I changed:

This is not in nginx.conf. It is in the sites-available directory and symlinked to sites-enabled which is included within nginx.conf.


listen 80; server_name name.co.uk; access_log /var/log/nginx/forums.access.log; error_log /var/log/nginx/forums.error.log; root /var/www/forums/someotherdirectory/public_html; location /{ //No need for /var/www/forums/.... here. autoindex on; //Not really necessary, I was trying to debug, still never managed to get indexing to work anyway! index index.php index.htm index.html; //Can probably come out of the location block try_files $uri $uri/ /var/www/fourms/someotherdirectory/public_html/index.php?q=$uri&$args; //Rewriting as shown above } ## Parse all .php files in the /var/www directorylocation ~ .php$ {fastcgi_split_path_info ^(.+.php)(.*)$; fastcgi_pass backend;fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; (used to be /var/www <- This was the final piece of the puzzle, before this I tried /var/www/fourms/someotherdirectory/public_html/ which failed, after this correction was made the actual site worked, albeit missing its css which was due to the incorrect board_url in the conf_global file.) include fastcgi_params; fastcgi_intercept_errors on; fastcgi_ignore_client_abort off; fastcgi_connect_timeout 60;} } upstream backend {server 127.0.0.1:9000;}

server {











Now the most important thing that prevented errors for me after this point was in nginx.conf the user directive was set to www-data. Whereas our files were chowned game:modg. In an attempt to not further modify permissions to 777 for everything xD! I changed the user directive to the owner of the files and this made the 403 errors disappear.

Some of my sources:

http://nginxlibrary....orbidden-error/
http://www.webhostin...ad.php?t=892228

I hope this helps.

Link to comment
Share on other sites

I have config files like this in /etc/nginx/sites-available. These are symlinked to sites-enabled and loaded in nginx.conf from there.

After finding out that these configs worked, but routing was incorrect continuously.

After starting from near blank config files to work out why my root directive was incorrect I discovered that it wasn't. Nginx roots all requests to the first root found if no other server name is defined. So why were my configs doing that?

I decided to check permissions in both sites-available and in sites-enabled with ls -la. Only to see the symlinks were incorrect.

default > default
and
forums > /etc/nginx/sites-available/forums

The default config symlink was incorrect. Definitely check this if you can't get the vhosts to route correctly.

I found out that you can't use relative paths in symlinks.

ln -s default /etc/nginx/sites-available/default << DOES NOT WORK! You need to explicitly state paths in both cases.

Link to comment
Share on other sites

  • 3 months later...
  • 1 year later...

I know this thread is pretty old but I wanted to leave my Nginx configuration here in case someone else finds it useful.

I am running Nginx with PHP5 FPM on a Debian 7 (wheezy).

I also use IP.Content

My forum is located at www.styleguise.net/forums/ and is installed at /usr/share/nginx/www/forums

For the forums, I have friendly URLs (FURL) enabled and in the SEO section of System Settings I have mod_rewrite "on".

You can turn on "Redirect to new friendly URL format" if you wish although it doesn't have any bearing on the rest of this stuff (I have mine "on").

I have IP.Content serving up my "homepage" at www.styleguise.net/

Additionally, I have several IP.Content pages that are served up off the root, for example www.styleguise.net/articles

In the IP.Content app settings, I have mod_rewrite "on" (this basically just configures friendly URLs for IP.Content) and my gateway file (ipcontent/Tools/index.php) lives at the root of my web directory (/usr/share/nginx/www/index.php)

Here is my nginx configuration file:

server {
    listen 80;
    root /usr/share/nginx/www;
    index index.php;
    server_name styleguise.net www.styleguise.net;

    #matches any path that starts with a slash.
    #it tries to match the url to a file, then to a directory
    #and finally to the ipcontent gateway file in /index.php
    location / {
        try_files $uri $uri/ /index.php;
    }

    #matches any path that starts with /forums
    #it tries to match the url to a file, then to a directory
    #and finally to the forum index file in /forums/index.php
    location /forums {
        try_files $uri $uri/ /forums/index.php;
    }

    #matches any path that ends with ".php" and dispatches
    #execution of the php script to PHP5-FPM daemons
    location ~ .php$ {
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
    }

    #deny access to .htaccess files (you probably don't have any if you are using nginx)
    location ~ /.ht {
        deny all;
    }
}
Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy