Kirby pointing to vendor/getkirby serverside

After out last deployment, we had this issue where absolutely nothing worked (Front & Back) including the panel that displayed the following message : " The panel cannot be installed".

After some tests, I was able to figure that after our last deploy, Kirby “decided” to point to the getkirby folder inside vendor for absolutely everything .

I guess that it seems to be the root of the problem as it should not point inside the vendor folder. When trying to print bunch of informations (ex: options, blueprints, site) directly through index.php, all we get are empty strings. However, when printing routers & routes, we get these path pointing toward vendor/getkirby as displayed below. FYI, locally, everything works and the print test display the proper information and paths


SERVER SIDE

[roots] => Kirby\Cms\Ingredients Object
(
    [kirby] => .../vendor/getkirby/cms
    [i18n] => .../vendor/getkirby/cms/i18n
    [i18n:translations] => .../vendor/getkirby/cms/i18n/translations
    [i18n:rules] => .../vendor/getkirby/cms/i18n/rules
    [index] => .../vendor/getkirby
    [assets] => .../vendor/getkirby/assets
    [content] => .../vendor/getkirby/content
    [media] => .../vendor/getkirby/media
    [panel] => .../vendor/getkirby/cms/panel
    [site] => .../vendor/getkirby/site
    [accounts] => .../vendor/getkirby/site/accounts
    [blueprints] => .../vendor/getkirby/site/blueprints
    [cache] => .../vendor/getkirby/site/cache
    [collections] => .../vendor/getkirby/site/collections
    [config] => .../vendor/getkirby/site/config
    [controllers] => .../vendor/getkirby/site/controllers
    [languages] => .../vendor/getkirby/site/languages
    [logs] => .../vendor/getkirby/site/logs
    [models] => .../vendor/getkirby/site/models
    [plugins] => .../vendor/getkirby/site/plugins
    [sessions] => .../vendor/getkirby/site/sessions
    [snippets] => .../vendor/getkirby/site/snippets
    [templates] => .../vendor/getkirby/site/templates
    [roles] => .../vendor/getkirby/site/blueprints/users
)

LOCAL SIDE

[roots] => Kirby\Cms\Ingredients Object
(
    [kirby] => .../backend/kirby
    [i18n] => .../backend/kirby/i18n
    [i18n:translations] => .../backend/kirby/i18n/translations
    [i18n:rules] => .../backend/kirby/i18n/rules
    [index] => .../backend
    [assets] => .../backend/assets
    [content] => .../backend/content
    [media] => .../backend/media
    [panel] => .../backend/kirby/panel
    [site] => .../backend/site
    [accounts] => .../backend/site/accounts
    [blueprints] => .../backend/site/blueprints
    [cache] => .../backend/site/cache
    [collections] => .../backend/site/collections
    [config] => .../backend/site/config
    [controllers] => .../backend/site/controllers
    [languages] => .../backend/site/languages
    [logs] => .../backend/site/logs
    [models] => .../backend/site/models
    [plugins] => .../backend/site/plugins
    [sessions] => .../backend/site/sessions
    [snippets] => .../backend/site/snippets
    [templates] => .../backend/site/templates
    [roles] => .../backend/site/blueprints/users
)

Additional informations

  • Kirby is in stalled and updated through composer
  • We use kirby 3.5.8 and can’t upgrade for technical reason, but that should not be that big of a deal.
  • The only changes on this deployment are a few blueprint updates, absolutely nothing else
  • No config files were modified (neither package or composer)

Please post your

  • index.php
  • folder structure
  • config.php
  • .htaccess

To me this looks like some configuration issue, either on your Kirby site, or server side or with composer.

VoilĂ  @texnixe :

1. index.php

<?php
require 'kirby/bootstrap.php';
echo (new Kirby)->render();

2.1 config.php

(this one is not loaded at all as Kirby try to get it from the vendor/getkirbyfolder)

<?php

$hooks = require_once(__DIR__ . '/hooks.php');
/*
  KIRBY SETTINGS
*/

return [
  'debug' => true, // since the files is not being loaded, the debug do not work
  'languages' => true,
  'panel' => [
    'install' => true,
    'css' => 'build/global.css',
    'js' => 'https://cdn.tailwindcss.com'
  ],
  'markdown' => [
    'extra' => true
  ],
  'api' => [
    'basicAuth' => true,
    'allowInsecure' => true
  ],
  'thathoff' => [
    'git-content' => [
      'disable' => true
    ],
  ],
  'hooks' => $hooks,
  'siteUrl' => 'http://localhost:3000'
];

2.2 config.domain_name.com.php

<?php
/*
 * Overrides some default settings from config.php
 */
return [
  'debug' => true
  'api' => [
    'allowInsecure' => false
  ],
  'thathoff' => [
    'git-content' => [
      'disable' => false,
      'branch' => 'main',
      'pull' => true,
      'commit' => true,
      'push' => true,
      'displayErrors' => true
    ],
  ],
  'siteUrl' => 'https://domain_name.com'
];

3. .htaccess

No htaccess (we connect to the backend using a third party frontend using the API


4. File structure

assets/
build/
 - global.css
cgi-bin/
composer.json
composer.lock
content/
index.php
kirby/
 - assets/
 - bootstrap.php
 - cacert.pem
 - composer.json
 - composer.lock
 - config/
 - dependencies/
 - i18n/
 - kirby.pub
 - panel/
 - router.php
 - src/
 - SECURITY.md
 - views/
logThis.php
media/
migration_headings.js
migration_headings.json
migration_headings.md
migration_headings.sh*
node_modules/
package-lock.json
package.json
postcss.config.js
README.md
robots.txt
scripts/
site/
 - accounts/
 - blueprints/
 - cache/
 - config/
 - languages/
 - plugins/
 - sessions/
 - snippets/
 - templates/
tailwind.config.js
vendor/
 - autoload.php
 - bin/
 - bnomei/
 - brick/
 - claviska/
 - composer/
 - coyl/
 - diesdasdigital/
 - filp/
 - getkirby/
   - composer-installer/
   - cms/ //should not be here
   - kql/ //should not be here
   - media/ //should not be here
   - site/ //should not be here
   - content/ //should not be here
 - hananils/
 - hidehalo/
 - laminas/
 - league/
 - michelf/
 - mullema/
 - mustangostang/
 - oblik/
 - paragonie/
 - phpmailer/
 - psr/
 - ramsey/
 - sylvainjule/
 - symfony/
 - thathoff/
 - true/

In addition, the print of route
https://res.cloudinary.com/ktryn/raw/upload/v1657228322/Public/routes.txt.zip

Didn’t you say you are trying to access the Panel?

So the files are actually present in the vendor folder. Then the first step would be to remove them. Question is how they ended up there.

My bad, here is the htaccess file content @texnixe

# 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>

<IfModule mod_headers.c>
    Header set Access-Control-Allow-Origin "*"
    Header set Access-Control-Allow-Origin "localhost"
    Header set Access-Control-Allow-Origin "localhost:3000"
</IfModule>tjhost@xxx [~/domain_name.com]#

I was able to solve the problem by changing the Kirby loader in index.php

Il doit y avoir un truc qui n’a pas été fait correctement dans l’installation à l’iniutial… J’i fait cette modification sur le fichier suivant en ligne

From this:

/* require __DIR__ . '/kirby/bootstrap.php';
echo (new Kirby)->render(); */

To this

require 'vendor/autoload.php';
echo (new Kirby([
  'roots' => [
    'index' => __DIR__
  ]
]))->render();

Now I need to figure out with the the main developper why it is behaving like this. I will try to come back with the reason behind this issue as soon as we find it.

Finally, we simplified the loader with this and it works:

require __DIR__ . '/kirby/bootstrap.php';
echo (new Kirby([
  'roots' => [
    'index' => __DIR__
  ]
]))->render();

The additional line that modify the value of roots.index for __dir__ is telling kirby that the kirby seems to remove the weird request pointing toward vendor/getkirby. There are some other weird bugs related to this that I still don’t understand, especially since these issue are not happening when testing locally… I don’t think I can or even want to dig further to understand as I need to modify the live server to figure this bug out, which I will avoid…