Currently Kirby limits on which server technology you may install the panel. Even though the list is configurable, it’s purpose is debatable. Example: We use the Symfony Server for about 2,5 years now for every Kirby project without any trouble.
I propose to remove the check for allowed server configurations, especially since the default options are not explicitly tested either (https://github.com/getkirby/kirby/pull/2654#issuecomment-647741144)
I support this, however we first need to check what the original reason for the server check was and whether it is still relevant. @Bastian?
I think this has been a simple support reason: Kirby not running on all environments without problems and us not being able to give support on many we aren’t familiar with. Or also people just not even considering their environment as source of the problem and not mentioning it when reporting an issue.
I still think this could be changed as you suggest. I would still think we should very clearly outline in the docs a limited list of environments we really support (and others can be used at their own risk). And we probably need to really force it in bug reports to mention if apache, Nginx or something else.
We could maybe turn it into a block list instead. I know that Windows Server caused multiple issues in the past. But if we only have a couple problematic servers, it makes more sense to turn it around.
I think even Microsoft IIS can be made to work with Kirby. So I don’t think we need to block anything at the moment.
I agree with Nico that we should solve this with docs and in support. With the system view it is now really easy to see the used server when writing a support request or bug report.
@Lukas Bestle sounds also good to me
Maybe it is helpful to add a button to the system view, that copys the essential information about the environment to the clipboard (PHP version, server software, Kirby version, installed plugins with version, …)? This could then be included wherever a user seeks support (Email, GitHub, Discord, Forum, …)
I love the idea @Benedict
I think it could also still make sense to indicate in the Panel view if the server is supported or not. Or do you think this would be too negative?
I feel like this could be confusing to clients. They would then ask their devs what the warning means and if it affects them.
And one would need a solid list of supported and unsupported server environments, which does not exist yet and is hard to compile. As Lukas said, I also think you can make Kirby work with IIS, it is just up to your server skills.
@Benedict To be fair, there is a definite list of what servers are supported: https://getkirby.com/docs/guide/quickstart#requirements
We get that some people might want to use it with more server choices and easing this for them is what this idea is about. But just because we’d remove the block, doesn’t mean that we would see more servers as supported. That’s gonna be still just these.
@Lukas Bestle I get that, but wouldn’t only the ones that understand this kind of matter in general have access to the system Panel view? I am a bit hesitant to throw out the blocklist and give no indication at all if someone uses a supported server or not.
@Nico What I meant is that this list is not thoroughly tested either, as @Lukas Bestle mentionend in the original GitHub ticket. I get your point though 👍
@Nico TBH I really think no server is unsupported. You can get any web server to work with Kirby as long as it supports URL rewriting and handles requests and responses according to web standards, but that should be the case with 99% of servers.
The only disadvantage of using other servers is that we don’t provide docs for them and probably have a hard time providing support. But on the other hand, LiteSpeed is in the list, however we don’t have docs for that either.
So I think the idea of having supported vs unsupported servers is more or less outdated and should be reconsidered. I think we should replace our communication with “Apache works out of the box, nginx and Caddy work with our cookbook recipes and other servers can be used by advanced users”.
wouldn’t only the ones that understand this kind of matter in general have access to the system Panel view?
Probably, but maybe not always. I can already see requests to provide a way to disable that warning, at which point we are at the option again that we already have. Maybe we could try it out and see if removing the block creates any more work in support. Combined with the simple way to copy the system information to the clipboard, I feel like it could be manageable. If not, we can still re-introduce a warning later.
@Lukas Bestle Maybe it’s just semantics, but for me supported servers means that we offer docs and support for them. Unsupported doesn’t mean they won’t work at all, it just means we can’t quite help you if it doesn’t work directly. You need to figure it out youself.
Yes, I agree with that. What do you think about this:
Apache works out of the box, nginx and Caddy work with our cookbook recipes and other servers can be used by advanced users
LiteSpeed would be removed from the list of supported servers in the docs. The Panel would no longer check the server and in support we would still ask for the used server when the issue could be server-related.