Error 500 when accessing the /admin/tools/scheduler page

1

Hello, colleagues!

At some point, when I go to the /admin/tools/scheduler page, I started getting Error 500.
Not on one site, but on all of them.
What could be the matter?
What additional information should I provide?

Thank you!

P. S. I checked permissions in folders and files.
Everything is installed via Linux on the www-data user and the necessary permissions:

sudo chown -R www-data:www-data /var/www/${MY_DOMAIN}
sudo chmod -R a=r,u+w,a+X /var/www/${MY_DOMAIN}
sudo chmod -R a=rx,u+wx,go+x /var/www/${MY_DOMAIN}/public/bin/*

Screenshot 2024-06-15 105936
Screenshot 2024-06-15 1059361885Ă—821 80 KB

Screenshot 2024-06-15 110333
Screenshot 2024-06-15 110333830Ă—575 22.7 KB

2

Doesn’t sound like permissions issue. Did you update Grav admin? Or maybe something on server changed?

3

Sure, all of plugins are updated, incl. Admin, and Grav is the last updated version too.
I’m completely at a loss…

As for the server, and I have a Caddy, I don’t even know which way to look.
I understand it roughly, but I have not made any significant changes. Although with your reply, I will now intentionally look at it!

The question remains open for now. I will be glad to have any additional ideas!

4

hm, I’m just experimenting with Caddy for https://immich.app/ because its easy reverse proxy feature, and found it quite good for this purpose, but, also saw that it is quite different to apache or nginx, so there might be some problems w.r. running a Grav site on Caddy.
you could check caddy-php and experiment with php versions to see if this solves your problem.
just a wild guess…

1 Like
5

What does Caddy have to do with it, if it’s an APPLICATION-LEVEL error?
All other sections of both the frontend and the backend work perfectly!

The question is different: how can I understand from the backtrace where the error occurs?
To understand this, you need to have a Grav architect qualification.
And the Grav developers are silent.

Where should I contact?

6

I have similar sites running in the same environment.
But on some everything is fine, on others the error is 500 when trying to open the Admin/Scheduler page!

7

Check what’s on the scheduler twig template on line 5 from your screenshot. Or I might check that later when I’m at my PC if I won’t forget :grinning:

1 Like
8

Thank you for your attention!

I have not changed any templates, all templates are from the standard package.

Moreover, as a result of painstaking research, I was able to reproduce this error as follows:

One by one, I downloaded and installed older versions of “Grav + Admin” bundle from Releases · getgrav/grav · GitHub.

Finally, I managed to find the version starting from which The Error appears:

  1. Installing grav-admin-v1.7.25.zip, I do not make any settings and changes, I do not update the system and plugins.
    And as soon as I enter Control panel, I immediately go to the Tools/Scheduler section.
    The section page opens, everything is fine.

  2. Installing grav-admin-v1.7.26.zip, I also do not make any changes, I immediately go to the Tools/Scheduler section.
    And I get an Error 500.
    Similar to the one described.
    Not in line 5 of the template, but in line 4, but with the same trouble.

  3. In the first two cases, I run Grav under PHP 8.1.
    But The Error disappears if I run Grav under PHP 7.4!

  4. Thus, we can conclude that The Error appears in Grav version 1.7.26 @ PHP 8.1.

  5. How do I report this “discovery” to the developers?

The Caddy Server (@ Ubuntu 20.24) configuration is taken from the template offered in the Grav distribution.
In my case, the configuration looks like this:

encode zstd gzip
root * /var/www/DOMAIN/public
file_server
## PHP 7/8:
#php_fastcgi unix//run/php/php7.4-fpm.sock
php_fastcgi unix//run/php/php8.1-fpm.sock

## Grav:
# Begin - Security
# deny all direct access for these folders
rewrite /(\.git|cache|bin|logs|backups|tests)/.* /403
# deny running scripts inside core system folders
#rewrite /(system|vendor)/.*\.(txt|xml|md|html|yaml|yml|php|pl|py|cgi|twig|sh|bat)$ /403
# Grav Update ↑↓
rewrite /(system|vendor)/.*\.(txt|xml|md|html|htm|shtml|shtm|yaml|yml|php|php2|php3|php4|php5|phar|phtml|pl|py|cgi|twig|sh|bat)$ /403
# deny running scripts inside user folder
#rewrite /user/.*\.(txt|md|yaml|yml|php|pl|py|cgi|twig|sh|bat)$ /403
# Grav Update ↑↓
rewrite /user/.*\.(txt|md|yaml|yml|php|php2|php3|php4|php5|phar|phtml|pl|py|cgi|twig|sh|bat|csv)$ /403  # JOO ADD *.csv
# deny access to specific files in the root folder
rewrite /(LICENSE\.txt|composer\.lock|composer\.json|nginx\.conf|web\.config|htaccess\.txt|\.htaccess) /403
respond /403 403
## End - Security
# global rewrite should come last.
try_files {path} {path}/ /index.php?_url={uri}&{query}

PHP is installed in the following configuration:

# PHP 7.4
sudo apt install php7.4 php7.4-bcmath php7.4-cli php7.4-common php7.4-curl php7.4-fpm php7.4-gd php7.4-json php7.4-mbstring php7.4-mysql php7.4-xml -y php7.4-zip php7.4-apcu php7.4-opcache php7.4-yaml php7.4-xdebug php7.4-bz2 php7.4-sqlite3 php7.4-mail

# PHP 8.1
sudo apt install php8.1 php8.1-bcmath php8.1-cli php8.1-common php8.1-curl php8.1-fpm php8.1-gd php8.1-mbstring php8.1-mysql php8.1-xml -y php8.1-zip php8.1-apcu php8.1-opcache php8.1-yaml php8.1-xdebug php8.1-bz2 php8.1-sqlite3 php8.1-intl php8.1-soap php8.1-redis

If it matters, on Grav sites I use templates with Gantry 5 @ RocketTheme - Grav Themes

Thanks!

9

Hello!

By the way, thanks a lot for the helpful link!

Everything is formulated succinctly and competently.
Perhaps it will be useful for some of our like-minded people.

:blue_heart::+1:t2:

P. S. And you were right about the PHP version! )

10

ok, that’s fine :smile: .
then you can mark the issue as resolved, right ?

1 Like
11

I believe this would be the place

1 Like
12

This problem is not solved, but rather marked for me.
After all, no one will downgrade the PHP version because of a strange error deep in the application code?

In addition, there is another mystical moment:

I have several sites, and this error occurs everywhere.

Everywhere… except for one site!
One of the sites is running PHP 8.1 on a completely updated system and plugins, but this error is not there.

So first I will write to the plugin developers, wait for their response, then draw conclusions, and then the issue can be considered officially resolved. )

Thanks! :handshake:t2:

13

Thank you very much!

If you have a minute of free time to answer, please help me figure out the organizational issue:
How do the messages in these topics (Discourse @ GetTrav) relate to the official bug tracker on GitHub?
Do developers come here sometimes? Or is communication here just for enthusiasts?

Thank you again! :raised_hand:t2:

14

tl;dr
Devs come here very rarely

More detailed explanation can be found here

1 Like
15

Thanks a lot for the link!

Those simple and obvious things must always be remembered, but sometimes it is useful to remind. )

:fist:t2: