Grav-plugin-admin: Regression: Ajax error in ngnix

[slyholborn]

Hello, after update to 1.6.3 (and update to 1.3.5) i've got issues in the admin pannel : the site seems to work well allthough, exept featherlight wich wouldn't work before update anyway. As i need a gallery, i also need to deal with this error for i'm sure it has no link between.
Thanks!

`Fetch Failed:
can't convert undefined to object

value/<@http://lelogisencorse.ddns.net/user/plugins/admin/themes/grav/js/admin.min.js?1451599962:5:23728
o/<@http://lelogisencorse.ddns.net/user/plugins/admin/themes/grav/js/admin.min.js?1451599962:4:27913

Invalid AJAX response.` 

[slyholborn]

I cannot put media on pages no more via the admin pannel : as soon as i save, they disapear after refresh. It works well by putting images in directory, but non of them appears on admin page. They are on the site

I cannot logout anymore

[ngocgiang2512]

I have the similar issue after update plugins. It warns whenever I click on saved button.

[rhukster]

Can you guys please provide some details regarding your webserver and php version?

[mitchellkrogza]

Yes me too, brand new site and I stupidly updated it to 1.3.5 now all sorts of Ajax errors. Also cannot even logout of Admin keeps giving "Invalid Security Token". Hope it can be fixed soon.

@rhukster

Server nginx version: nginx/1.12.1

PHP 7.0.22-0ubuntu0.16.04.1 (cli) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.0.22-0ubuntu0.16.04.1, Copyright (c) 1999-2017, by Zend Technologies

Other sites still running 1.3.4 of Grav all working 100%

Clicking on ANY of the menu items on the left gives Ajax Error

[rhukster]

BTW, can you guys help me out by first backing-up/copying your system/src/Grav/Common/Uri.php file and then try putting back the version from Grav 1.3.4: https://github.com/getgrav/grav/blob/1.3.4/system/src/Grav/Common/Uri.php

If that sorts it, we can narrow things down. We did some refactoring on this class and I think it's what's leading to your issues.

[mitchellkrogza]

@rhukster I can confirm that fixes the issue

[rhukster]

Still would be helpful to know your environment information because I can't replicate this on my local test installs.

[mitchellkrogza]

@rhukster another issue to add here. Simple markdown is not working either.

<center>![](motsepe-commercial-photography-projects-logo.jpg)</center>

Renders as:

and using custom.css in antimatter which only contains one line in it .centerimage { display: block; margin: 0 auto; }

If I do ![](motsepe-commercial-photography-projects-logo.jpg){.centerimage} it renders the page as follows

[mitchellkrogza]

@rhukster exactly what do you need to know from my environment? I am happy to provide anything you need.

[rhukster]

That's IMG/markdown things is actually nothing related to this, that's a problem with markdown extra? That is not regular markdown because you cannot put markdown inside HTML tags with regular markdown. The better way to fix that is with:

![](motsepe-commercial-photography-projects-logo.jpg?classes=centerimage)

[rhukster]

• Webserver (apache/nginx), if nginx, webserver config file.
• PHP version

To start with

[mitchellkrogza]

Thanks @rhukster but that previously worked perfectly on 1.3.4 (still does) ie. adding the class at the end like that.

I provided that info earlier up

Nginx 1.12.1

PHP 7.0.22-0ubuntu0.16.04.1 (cli) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.0.22-0ubuntu0.16.04.1, Copyright (c) 1999-2017, by Zend Technologies

nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
    worker_connections 1024;
    multi_accept on;
    use epoll;
}

http {

    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 90s;
    keepalive_requests 1000;
    server_tokens off;
    client_body_buffer_size 32k;
    client_header_buffer_size    1k;
    client_max_body_size 50M;
    types_hash_max_size 2048;
    large_client_header_buffers 4 16k;
    variables_hash_max_size 2048;
    variables_hash_bucket_size 1024;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;


    # Our request limiter zone for wp-login attacks
    limit_req_zone $binary_remote_addr zone=wp-login:10m rate=1r/s;

    # Add FastCGI caching
    # https://www.nginx.com/blog/9-tips-for-improving-wordpress-performance-with-nginx/
    # Set Caching Zones - I am keeping these separate for now - easier to purge and control

    open_file_cache                 max=10000 inactive=5m;
    open_file_cache_valid           1m;
    open_file_cache_min_uses        1;
    open_file_cache_errors          on;

    fastcgi_cache_key "$scheme$request_method$host$request_uri";
    fastcgi_cache_use_stale error timeout invalid_header updating http_500;

    fastcgi_cache_path /var/cache/nginx/general levels=1:2 keys_zone=GENERAL:100m inactive=100m;

    ##
    # Logging Settings
    ##

    log_format  custom  '$remote_addr - $http_x_forwarded_for $remote_user $server_port [$time_local] "$request" '
                  '$status "$http_referer" "$http_user_agent" "$http_header"'
                  '"$body_bytes_sent" - "$gzip_ratio"';


    access_log /var/log/nginx/access.log main_ext;
    error_log /var/log/nginx/error.log warn;


    ##
    # Gzip Settings
    ##

    gzip on;
    gzip_disable "MSIE [1-6]\.";
    gzip_vary on;
    gzip_static on;
    gzip_min_length 20;
    gzip_proxied expired no-cache no-store private auth;
    gzip_comp_level 7;
    gzip_buffers 32 4k;
    gzip_http_version 1.1;
    gzip_types text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    ##
    # Virtual Host Configs
    ##

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

[mitchellkrogza]

The ![](motsepe-commercial-photography-projects-logo.jpg?classes=centerimage) fixes that and I learned something new about how to do that so thanks @rhukster

[rhukster]

Can you guys who are having this problem, inspect the XHR requests for the Ajax calls?

In chrome, this in web developer tools -> network -> xhr

Then reload the page and inspect the Request URL and the response

[rhukster]

Actually if any of you could PM me directly on slack with login details to your site, that would help a lot and be much appreciated.

[rhukster]

@mitchellkrogza can you also include your php nginx configuration? specifically the PHP bit, like:

    ## Begin - PHP
    location ~ \.php$ {
        # Choose either a socket or TCP/IP address
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        # fastcgi_pass 127.0.0.1:9000;

        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
    }
    ## End - PHP

[mitchellkrogza]

Here you go:

    # BEGIN - Index

    # for subfolders, simply adjust:
    # `location /subfolder {`
    # and the rewrite to use `/subfolder/index.php`

    location / {
        try_files $uri @index;

    location /assets {
            gzip_static on;
            }
        }

    location @index {
        try_files = /index.php?_url=$uri&$query_string;
    }

    ## END - Index

    ## BEGIN - Security

    # set error handler for these to the @index location
    error_page 418 = @index;
    # deny all direct access for these folders
    location ~* /(\.git|cache|bin|logs|backup|tests)/.*$ { return 418; }
    # deny running scripts inside core system folders
    location ~* /(system|vendor)/.*\.(txt|xml|md|html|yaml|yml|php|pl|py|cgi|twig|sh|bat)$ { return 418; }
    # deny running scripts inside user folder
    location ~* /user/.*\.(txt|md|yaml|yml|php|pl|py|cgi|twig|sh|bat)$ { return 418; }
    # deny access to specific files in the root folder
    location ~ /(LICENSE\.txt|composer\.lock|composer\.json|nginx\.conf|web\.config|htaccess\.txt|\.htaccess) { return 418; }

    ## END - Security


    ## BEGIN - PHP

    location = /index.php {

        ## BEGIN - FastCGI caching

        fastcgi_cache_bypass $no_cache1 $no_cache2;
        fastcgi_no_cache     $no_cache1 $no_cache2;
        fastcgi_cache           GENERAL;
        fastcgi_cache_key       "$scheme$request_method$host$request_uri$sessionkey";
        fastcgi_cache_valid     200 30m;
        fastcgi_cache_valid     404 5m;
        fastcgi_cache_valid     any 1m;
        fastcgi_ignore_headers  "Cache-Control"
                                "Expires"
                                "Set-Cookie";

        fastcgi_cache_use_stale error
                                timeout
                                updating
                                http_429
                                http_500
                                http_503;

        fastcgi_cache_background_update on;

        ## END - FastCGI caching

        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;


        # Choose either a socket or TCP/IP address
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
        }

    ## END - PHP

        ## Begin - PHP Security

        # deny access to other .php-scripts
        location ~ \.php$ { 
            return 418; 
            }

        ## END - PHP Security

    ## BEGIN - Cache Purge Settings 

    location ~ /purge(/.*) {
        fastcgi_cache_purge GENERAL "$scheme$request_method$host$1";
    }   

    ## END - Cache Purge Settings   

[mahagr]

I'm able to reproduce the issue, trying to locate the issue now. Thanks for the detailed help!

[mitchellkrogza]

No problem whatsoever.

[slyholborn]

Don't know if it's still usefull but i'm on
ngnix
PHP Version 5.6.30-0+deb8u1
on raspbian Jessie

[mahagr]

Nope, it wasn't that. Can you please come to grav chat? I need your help to figure this out.

[rhukster]

I'm setting up a raspberry pi / nginx setup to see if i can replicate it too.

@slyholborn what does your nginx.conf look like?

[slyholborn]

I post it as soon as i can acces the server. I'm at work without my ssh keys...

[rhukster]

Ok, i've narrowed it down to Nginx, and specifically the try_files part of the configuration. My test site had simply:

location / {
        try_files $uri $uri/ /index.html /index.php;
}

And this worked, however, the webserver-configs/nginx.conf file (and possibly other places has been updated so it looks like this:

location / {
        try_files $uri $uri/ /index.php?_url=$uri&$query_string;
}

When I change it to this, and restart nginx, it breaks with that ajax error. So i removed the &$query_string at the end, and it worked.

So something related to the query_string in this nginx configuration and the changes/fixes we made in the URI class are breaking it.. Not fixed yet, but narrowing things down.

[mahagr]

Yeah, do not remove the query_string part! It's really needed :)

[rhukster]

Yah this is not the solution, but it is narrowing things down for us.. just giving you guys a running commentary. If you can test that removing it 'does' fix your ajax issues, then we are solving the same problem you are having... that's all..

[peracchi]

Info from my system (Mac OS X El Capitan 10.11.6) below. If more details can help, please ask.

$ php -v
PHP 7.1.9 (cli) (built: Sep  4 2017 10:20:56) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies

$ nginx -v
nginx version: nginx/1.12.1

/usr/local/etc/nginx/servers $ cat cbea.dev
server {
    #listen 80;
    index index.html index.php;

    ## Begin - Server Info
    root /Users/peracchi/development/grav/cbea.dev;
    server_name cbea.dev;
    ## End - Server Info

    ## Begin - Index
    # for subfolders, simply adjust:
    # `location /subfolder {`
    # and the rewrite to use `/subfolder/index.php`
    location / {
        try_files $uri $uri/ /index.php?_url=$uri&$query_string;
    }
    ## End - Index

    ## Begin - Security
    # deny all direct access for these folders
    location ~* /(\.git|cache|bin|logs|backup|tests)/.*$ { return 403; }
    # deny running scripts inside core system folders
    location ~* /(system|vendor)/.*\.(txt|xml|md|html|yaml|yml|php|pl|py|cgi|twig|sh|bat)$ { return 403; }
    # deny running scripts inside user folder
    location ~* /user/.*\.(txt|md|yaml|yml|php|pl|py|cgi|twig|sh|bat)$ { return 403; }
    # deny access to specific files in the root folder
    location ~ /(LICENSE\.txt|composer\.lock|composer\.json|nginx\.conf|web\.config|htaccess\.txt|\.htaccess) { return 403; }
    ## End - Security

    ## Begin - PHP
    location ~ \.php$ {
        fastcgi_pass 127.0.0.1:9000;

        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
    }
    ## End - PHP
}

[rhukster]

Yup, we have a fix.. a workaround for this _url=$uri part (in Uri.php class), and also we've changed the default nginx.conf example to remove this as it's not really needed.

[rhukster]

Ok, we're going to re-release Grav now with this fix.

[slyholborn]

Great!

[mitchellkrogza]

Thanks @rhukster and team for a quick fix. Updated this morning 1.3.6 and all is working again 👍

[slyholborn]

All works fin here too! Thanks!!

[mitchellkrogza]

Anyone stuck at 1.3.5 and unable to update it to 1.3.6 simply do the following

cd /var/www/yourgravsite/
sudo mv system/src/Grav/Common/Uri.php system/src/Grav/Common/BACKUP-Uri.php
sudo wget https://raw.githubusercontent.com/getgrav/grav/1.3.4/system/src/Grav/Common/Uri.php -O /var/www/yourgravsite/system/src/Grav/Common/Uri.php
sudo chown -R www-data:www-data /var/www/yourgravsite/

Then reload Admin and you will be able to update it.

[maxalmonte14]

I have the exact same issue as @mitchellkrogza, I'm working on local with the built-in PHP server, the php -v command show me

PHP 7.1.7 (cli) (built: Jul  6 2017 16:51:52) ( ZTS MSVC14 (Visual C++ 2015) x64
 )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies

And I have the latest Grav version v1.3.8

[rhukster]

Read the info above. The issue is probably the same as the original poster, you need to change your try_files line. It was broken before and shouldn't of worked, we fixed something and it brought this issue to the surface.

[maxalmonte14]

Thank very much, I'm gonna try your solution.

Only for an informational purpose, I have to say this it's not happening on Linux at least for me even working with the PHP built server and the same Grav project. (I'm using Linux Mint 18.2 x64)

In the previous message, I was working on Windows 10.

[colinwilson]

I'm experiencing this using my Built-in PHP Webserver, php -S localhost:8000 system/router.php.

Grav: 1.3.8

PHP 7.1.11 (cli) (built: Oct 25 2017 20:54:15) ( NTS MSVC14 (
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies

How do you adjust the try_files line in this case?

[rhukster]

@colinwilson can you please open a new ticket. This is a similar but different error that must be related to the system/router.php

[JOduMonT]

hum; Interesting...

I'm not sure if it's because I'm using freebsd 11.1-RELEASE-p8 with nginx/1.12.2 and PHP 7.1.15

but for me it's the inverse :
which I copied the nginx.conf from getgrav doc than I had this ajax error
so I i comment the ?q=$uri&$args and simply replace it by
try_files $uri $uri/ /index.php;

as this

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

it's work fine (without error)

[velsa]

I get all the errors possible with latest grav (Grav CLI Application version 1.4.3) and Ubuntu 16.04.4 LTS. Invalid security token appears when I click the Clear Cache button, Invalid AJAX - every time I refresh the page.
Enabled debug in user/config/system.yaml
Tried different nginx config options as described in this thread.

No errors in console, no errors in nginx error log.
No idea what to do next.

[mahagr]

@velsa Please create a new issue from this as nobody looks at closed issues. :)

[hughbris]

@velsa Please create a new issue from this as nobody looks at closed issues. :)

They really should though, unless you publish that you follow a workflow where they are deliberately ignored. Is it a notification issue? (let this be a test!)