Debugging Not Found front/panel

Kirby 3 Solved ✅
1

I am kind of suddendly getting a plain 404 Not Found server message on a site, both for the panel and the front.

This is a remote server I deploy in via git, and the local version is working, and both are up-to-date, in terms of code, according to git.

Locally I am running PHP 7.4.3. , remotely the server runs 7.3 but the right version is controlled by a handler in .htaccess by cPanel that reads:

 # php -- BEGIN cPanel-generated handler, do not edit
 # Set the “ea-php74” package as the default “PHP” programming language.
 <IfModule mime_module>
   AddHandler application/x-httpd-ea-php74 .php .php7 .phtml
 </IfModule>
 # php -- END cPanel-generated handler, do not edit

…the rest of the .htaccess file is kirby’s default.

If I move it all to a subfolder, and i let cPanel build another .htaccess with the handler, I can access a phpinfo() file and it shows 7.4.3 as expected

So I downloaded the remote content into localhost, see if it content was the culprit, but locally it still works.

There is a single config.php file, with debug => true

How can I continue debugging this one?

Thanks

2

I have uploaded the site at github with a basic content folder so others can troubleshoot.

Thank you

3

Shouldn’t the handler be at the top of the .htaccess?

4

I tried moving the handler block right before the # Kirby .htaccess line, but still the same result.

:thinking:

@texnixe, do you have the possibility of running that site at a remote server to see if it works ?

5

No, I don’t have a server that would react to this handler, I’m afraid.

If you add a php file with phpinfo() to the doc root, do you actually get PHP 7.4?

6

If I add , say , phpinfo.php to root, and try to access it, I still get not found

If I move all kirby files to a subfolder (including .htaccess) then add the phpinfo to root, it does work, and it shows 7.3

If I then go to to cPanel MultiPHP Manager, and ask it to use php 7.4 on this site, it creates a .htaccess at root, with the following content:

# php -- BEGIN cPanel-generated handler, do not edit
# Set the “ea-php74” package as the default “PHP” programming language.
<IfModule mime_module>
  AddHandler application/x-httpd-ea-php74___lsphp .php .php7 .phtml
</IfModule>
# php -- END cPanel-generated handler, do not edit

If I then access the same phpinfo file, it shows 7.4.28

7

With the same URL?

8

Yes, with https://domain.com/phpinfo.php

9

And the Kirby site works properly if it is located in a subfolder?

10

No it does not (although I did not try adding the folder name to RewriteBase at .htaccess)

Also, if I move kirby files to a subfolder, as explained, and copy Kirby’s .htaccess file, including the handler, back to root, that is enough to return not found when accessing phpinfo.php.

I am copying the whole .htacess file in case you may see something, note I moved the handler to the top as suggested:

# php -- BEGIN cPanel-generated handler, do not edit
# Set the “ea-php74” package as the default “PHP” programming language.
<IfModule mime_module>
  AddHandler application/x-httpd-ea-php74 .php .php7 .phtml
</IfModule>
# php -- END cPanel-generated handler, do not edit

# Kirby .htaccess
# revision 2020-06-15

# rewrite rules
<IfModule mod_rewrite.c>

# enable awesome urls. i.e.:
# http://yourdomain.com/about-us/team
RewriteEngine on

# make sure to set the RewriteBase correctly
# if you are running the site in a subfolder;
# otherwise links or the entire site will break.
#
# If your homepage is http://yourdomain.com/mysite,
# set the RewriteBase to:
#
# RewriteBase /mysite

# In some environments it's necessary to
# set the RewriteBase to:
#
# RewriteBase /

# block files and folders beginning with a dot, such as .git
# except for the .well-known folder, which is used for Let's Encrypt and security.txt
RewriteRule (^|/)\.(?!well-known\/) index.php [L]

# block all files in the content folder from being accessed directly
RewriteRule ^content/(.*) index.php [L]

# block all files in the site folder from being accessed directly
RewriteRule ^site/(.*) index.php [L]

# block direct access to Kirby and the Panel sources
RewriteRule ^kirby/(.*) index.php [L]

# make site links work
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.php [L]

</IfModule>

# pass the Authorization header to PHP
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

# compress text file responses
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE application/json
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
</IfModule>
11

Some additional tests

  1. If I move kirby installation back to root, including .htaccess with handler, etc… and then I remove or rename index.php, and try to access the domain, I get a 403 Forbidden instead, as expected, due to the lack of index.php and file listing being off

  2. If , with index removed or renamed, I also remove or rename .htaccess, create a phpinfo.php file at root and try to access it, it works, showing 7.3.33

  3. If I recover .htaccess, and try to access phpinfo, again not found

  4. If I comment the php 7.4 handler from .htaccess, and try to access phpinfo, it works

Would this suggest that the handler is screwing things ? or more like the handler in combination with the rest of kirby’s .htaccess file, because an .htaccess with only the handler works.

confused

12

I asked the hosting company to fix this, they added the handler via ‘backend command’, which added a slightly different handler, and that made the website work in all cases. This is the updatred, working handler:

# php -- BEGIN cPanel-generated handler, do not edit
# Set the “ea-php74” package as the default “PHP” programming language.
<IfModule mime_module>
     AddHandler application/x-httpd-ea-php74___lsphp .php .php7 .phtml
</IfModule>
 # php -- END cPanel-generated handler, do not edit

They are in the process of upgrading to php 8, so I am going to blame them on this.

Thanks @texnixe