Viewing 13 replies - 1 through 13 (of 13 total)
  • Plugin Author Rolf Allard van Hagen

    (@ravanh)

    Hi, have you tried disabling and re-enabling each of the post types again? Could you try going to the Settings > Permalinks page and resave the permalink settings?

    I have the same problem. Do this pug-in need a rewrite rules for Nginx?

    @photoua, no there are no special rules other than the usual WordPress rules for Nginx needed. Can you share link to your website?

    Yes, of course. http://www.malenko.com

    @photoua, the sitemap feed itself works fine (see http://www.malenko.com/?feed=sitemap) so it does indeed appear to be Nginx that is trying to serve an actual file instead of passing all requests to WordPress. For that to happen you should have a rule like

    location / {
    	try_files $uri $uri/ /index.php?$args;
    }

    which will pass all requests it cannot deal with over to index.php. You can see many examples (some out of date, actually) on http://codex.wordpress.org/Nginx.

    On my Nginx servers where a WordPress Multisite is running with WP Super Cache in PHP mode, I use slightly different rules but they boil down to these similar essentials:

    # Static
    location / {
    	error_page 404 = @wp;
    	log_not_found   off;
    }
    
    # WPMU rewrite rules. Blog name must be removed.
    location @wp {
    	# Old style media URLs
    	# rewrite /files/(.+) /wp-includes/ms-files.php?file=$1 last;
    
    	# Match only one section
    	rewrite ^/(wp-.*) $1 last;
    	rewrite ^(/[^/]+)?(/wp-admin/.*) $2 last;
    	rewrite ^(/[^/]+)?(/.*\.php) $2 last;
    
    	# Send everything else to index.php (permalinks)
    	# WP Super Cache compatible (no request variable)
    	rewrite ^/(.*)$ /index.php last;
    }
    
    # PHP scripts -> PHP-FPM server listening on 127.0.0.1:9000
    location ~ \.php$ {
    	# The following line prevents malicious php code to be executed through some uploaded file (without php extension, like image)
    	# This fix shoudn't work though, if nginx and php are not on the same server, other options exist (like unauthorizing php execution within upload folder)
    	# More on this serious security concern in the "Pass Non-PHP Requests to PHP" section, there http://wiki.nginx.org/Pitfalls
    	try_files $uri =404;
    
    	fastcgi_pass   php;
    	fastcgi_index  index.php;
    	include fastcgi_params;
    	fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    	fastcgi_param SERVER_NAME $http_host;
    
    	fastcgi_read_timeout 300;
    	fastcgi_next_upstream error timeout invalid_header;
    }

    RavanH! Thank yo for answer.

    My nginx config is similar. May I simply just not see an error?
    v_server.conf

    server {
      listen 80;
      server_name www.malenko.com malenko.com;
      root /var/www/malenko.com;
      charset utf-8;
    
      include         nginx-bp/cache.conf;
      include         nginx-bp/limits/methods.conf;
      include         nginx-bp/limits/uploads.conf;
    
      include         nginx-bp/locations/php.conf;
      include         nginx-bp/locations/favicon.conf;
      include         nginx-bp/locations/favicon_apple.conf;
      include         nginx-bp/locations/static.conf;
      include         nginx-bp/locations/system.conf;
      include         conf.d/wordpress.conf;
    
      access_log      /var/www/logs/malenko.com-access.log main buffer=32k; #buffering doesn't work with variables
      error_log       /var/www/logs/malenko.com-error.log warn; # error_log doesn't support variables
    
      include       nginx-bp/locations/purge.conf;
    
      location /
        {
    #      try_files   $uri $uri/ /index.php;
          try_files $uri $uri/ /index.php?$args;
        }
    }

    wordpress.conf

    #set $skip_cache 0;
    set $nocache 0;
    
    # POST requests and urls with a query string should always go to PHP
        if ($request_method = POST) {
                set $nocache 1;
            }
        if ($query_string != "") {
                set $nocache 1;
            }
    
    # Don't cache uris containing the following segments
        if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
            set $nocache 1;
            }
    
    # Don't use the cache for logged in users or recent commenters
        if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
            set $nocache 1;
            }
    
    # Deliver 404 instead of 403 "Forbidden"
            error_page 403 = 404;
    
    # Do not allow access to files giving away your WordPress version
             location ~ /(\.|wp-config.php|readme.html|licence.txt) {
             return 404;
             }
    
    # Add trailing slash to */wp-admin requests.
            rewrite /wp-admin$ $scheme://$host$uri/ permanent;
    
    # Deny access to any files with a .php extension in the uploads directory
    # Works in sub-directory installs and also in multisite network
        location ~* /(?:uploads|files)/.*\.php$ {
            deny all;
            }
    
    # Make sure files with the following extensions do not get loaded by nginx because nginx would display the source code, and these files can contain PASSWORDS!
        location ~* \.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)$|^(\..*|Entries.*|Repository|Root|Tag|Template)$|\.php_
            {
                    return 444;
            }
    
    #nocgi
            location ~* \.(pl|cgi|py|sh|lua)\$ {
                return 444;
                }
    
    #disallow
        location ~* (roundcube|webdav|smtp|http\:|soap|w00tw00t) {
                return 444;
                }
    
    # Rewrite for versioned CSS+JS via filemtime
            location ~* ^.+\.(css|js)$ {
            rewrite ^(.+)\.(\d+)\.(css|js)$ $1.$3 last;
            expires 31536000s;
            access_log off;
            log_not_found off;
            add_header Pragma public;
            add_header Cache-Control "max-age=31536000, public";
        }
    
    # Yoast WordPress SEO
            rewrite ^/sitemap_index\.xml$ /index.php?sitemap=1 last;
            rewrite ^/([^/]+?)-sitemap([0-9]+)?\.xml$ /index.php?sitemap=$1&sitemap_n=$2 last;

    @photoua – remove these last lines in your wordpress.conf:

    # Yoast WordPress SEO
            rewrite ^/sitemap_index\.xml$ /index.php?sitemap=1 last;
            rewrite ^/([^/]+?)-sitemap([0-9]+)?\.xml$ /index.php?sitemap=$1&sitemap_n=$2 last;

    Thanks, but it hasn’t resolved this problem.

    Did you restart the nginx service? And clear any caches?

    Yes, of course πŸ™‚

    There is a more ‘general’ rule (somewhere in the other conf files?) that keeps every query with an extension (like .xml .html or anything else) from falling back to index.php in case there is no actual file.

    See for instance the difference between /nonexistentpage/ and /nonexistantpage.html on your site. Same for .htm .jpg .png or .php but not (for example) .bmp or .asp or others. I would expect to see all WordPress generated 404 pages but instead, some are Nginx 404’s again…

    There must be some rule targeting all requests ending with .html .htm .jpg .php etc… Probably in nginx-bp/locations/static.conf ?

    I can’t find anything.

    # Expire rules for static content
    
    # No default expire rule. This config mirrors that of apache as outlined in the
    # html5-boilerplate .htaccess file. However, nginx applies rules by location,
    # the apache rules are defined by type. A concequence of this difference is that
    # if you use no file extension in the url and serve html, with apache you get an
    # expire time of 0s, with nginx you'd get an expire header of one month in the
    # future (if the default expire rule is 1 month). Therefore, do not use a
    # default expire rule with nginx unless your site is completely static
    
    # cache.appcache, your document html and data
    location ~* \.(?:manifest|appcache|html?|xml|json)$ {
      expires -1;
      access_log /var/www/logs/static.log;
    }
    
    # Feed
    location ~* \.(?:rss|atom)$ {
      expires 6h;
      add_header Cache-Control "public";
    }
    
    # Media: images, icons, video, audio, HTC
    location ~* \.(?:jpg|jpeg|gif|png|ico|gz|svg|svgz|mp4|ogg|ogv|webm|htc|swf)$ {
      expires 12M;
      access_log off;
      log_not_found   off;
      add_header Cache-Control "public";
    }
    
    # CSS and Javascript
    location ~* \.(?:css|js)$ {
      expires 1y;
      access_log off;
      add_header Cache-Control "public";
    }
    
    # WebFonts
    # If you are NOT using cross-domain-fonts.conf, uncomment the following directive
    location ~* \.(?:ttf|ttc|otf|eot|woff|font.css)$ {
      expires 1M;
      access_log off;
      add_header Cache-Control "public";
     }

    Hmmm, don’t see any rules that would apply here either… What if you move the rule

    location /
        {
    #      try_files   $uri $uri/ /index.php;
          try_files $uri $uri/ /index.php?$args;
        }

    in v_server.conf up to before all the includes?

Viewing 13 replies - 1 through 13 (of 13 total)

The topic ‘Custom Post sitemaps cause 404’ is closed to new replies.