Some Kirby sites not working on VPS


#1

I’m hosting a few Kirby sites and a Wordpress site through Virtual Hosts on a Digital Ocean 1GB droplet.

Despite everything having worked absolutely fine for while, I tried to log into one the panel of one of the sites and it returned a 500 error. Having reviewed all the sites hosted it seems two of the Kirby sites also return 500 errors at the root.

How can I go about debugging this?


#2

you can set debug true within config file. I have had 500 errors mostly when htaccess files had modifications such as additional parameters for caching and how to handle other things which my server didn’t support. so you should also take a look at those, if you were to modify htaccess…

<?php
// config/config.php
c::set('debug',true); 


#3

Have you checked other threads with Panel 500 errors, e.g. Panel 500 Error

Edit: You should also check your server error logs in addition to php error log. Depending on the sort of error, setting PHP debug to true might not help. If your php.ini settings are configured correctly, php errors should be logged to file, then no need to enable debug in config.php


#4

Thanks, I did this on the sites where the root also returns with a 500 error as well as the panel. It output the following:

“Fatal error: Namespace declaration statement has to be the very first statement or after any declare call in the script in /var/www/example.co.uk/public_html/kirby/kirby/registry/template.php on line 3”

Do you happen to know what this could mean?


#5

Thanks for replying. I did see that thread, mbstring is installed and enabled so I don’t think that is the issue. I’m trying to configure the php_errors.log now in the php.ini but it doesn’t seem to be outputting anything.


#6

do you have any namespaces declared within functions? (maybe within plugins etc which is trying to get called?)

namespaces need to be outside functions best very first lines…

<?php 
namespace Foo\Bar\subnamespace;
return function (....){

}

instead of

<?php 
// this will produce an error similar to yours
return function ($site,$pages,$page) {


namespace Foo\Bar\subnamespace;

// or anything similar to that
}

#7

@carstengrimm Don’t use a closing PHP tag in PHP only files.


#8

Have you checked if this same error occurs with a fresh starterkit as well?

What sort of plugins are you using? Something seems to be inserting something somewhere, maybe even said closing tags in PHP files (plugins?).


#9

I’m not using any plugins for the site I referenced then, however the same thing is happening to a Kirby site that does have a few plugins.

I just logged in to CyberDuck so I could navigate the files a little better. I noticed some very odd files.
On the left is a Kirby site that seems to work (i.e doesn’t return 500 error anywhere), in the middle the Panel returns a 500 error and the site on the right returns a 500 error at the root and the panel.

Has my server been compromised in some way? Could this be the problem?


#10

That looks pretty much like it. Are you using non secured FTP ? Or an ill maintained WP site? Using weak passwords?


#11

I’m using STFP over CyberDuck connecting through a sudo user to upload files I added the Wordpress site a few weeks ago had a few problems setting it all up and used 777 permissions whilst I figured out the problem, perhaps this is the breach? Amateur, I know. Fortunately this are small websites, no more than portfolio sites and blogs. Do you have any advice on how to rectify this? How can a Wordpress site be ill maintained?


#12

Not updated regularly.

But of course, I have no idea why your server was compromised.

Do you have backups of your Kirby sites? Maybe you can find out in the server logs when your server was hacked. I’d delete everything and replace with a backup that can’t possibly have been infected.

Most often, it seems, these things seem to happen when hosting provider still allows FTP access to the server. But there are many ways hackers can find their way in. Is this a managed server and do you maintain it yourself? There seems to be some scanning in place, otherwise those file with the .suspected extension wouldn’t exist, I guess.

So, time to tidy up.