First of all - the official Kirby documents doesn’t seem to have any sort of guide how to set the site up besides locally… why? This seems absurdly weird to me, for a paid software even.
Second; as someone who’s just starting out with web development (I’ve so far focused mainly on Javascript side of things), getting Kirby working seems rather complicated. Getting Apache up and running with Kirby took me several hours of trial and error keyboard smashing, googling, blood and sweat, and I’ve now come to the point where every page seems to work now without giving me errors… except the panel.
I’ve now faced with what seems like permission issues on the server (linode) where I want to host the Kirby site.
Am I really supposed to pull chgrp on each of these folder for www-data everytime, I want to “install” a fresh set of panel on my sites? Is there no better way to handle this without causing security issues? Am I going about this completely the wrong way? Please – do let me know…
Thank you.
Hm, usually, installing Kirby is nothing more than copying over the files to a server, and - depending on the environment - maybe set the rewrite base (unless you install on a non-Apache server).
File and folder permissions and the owner of the files is nothing Kirby could possibly take care of, but if necessary, these processes can be automated with a cron job. This is nothing Kirby specific, this is true for other CMS as well.
As regards the first issue message, this is actually a security feature. If you haven’t created a Panel user yet and want to access the Panel on the server, you have to explicitly allow this, otherwise the Panel would be unprotected.
I’m installing apache2 and PHP on a fresh image of Ubuntu 16.04 on Linode. I understand that this setup is completely out of Kirby’s responsibility, but I just wanted to express the frustration I’ve had for the couple of hours setting this up… And also maybe get some recommendations on how to make the process more streamlined. I am supposed to transfer the Kirby site to a shared hosting later down the road. Maybe it’ll be just as simple as drag and drop on FTP client there? (I certainly hope so)
Adding a little guide to the official docs on how to set things up from the ground up (not locally) could be extremely helpful for future reference.
Well, I understand that that is a lot of work, but this is nothing the Kirby documentation could ever cover.
Yes, thanks a lot for your feedback , we can certainly try to improve this, although in many (most?) cases it’s just transferring the files, installing the Panel and if it does not work out of the box, check out the troubleshooting guide. Maybe put it all into one document…?
I would suggest using Vagrant. Linode supply tools to spin up vagrant boxes that mimic the live Linode servers. Help guide.
Alternatively, I would install Webmin on the Linode box (asssuming linodes are just bare boxes with an OS on them only). That would at least give you easy configuration without all the terminal bashing. Webmin install guide
I feel your frustration @Yliaho as i also switched to hosting VPS that i manage myself.
Linux is no joke but it gets better over time :). It has nothing to do with kirby though. You can easily buy any php hosting and Kirby will work.
If you something more automatic and easy i would suggest either https://easyengine.io/ or https://serverpilot.io/. Easyengine is open source but command line only. Server pilot is full blown dashboard but its commercial product.
I don’t see how Vagrant @jimbobrjames suggested would help you. Vagrant is just virtual machine so you can have server with same settings on your local machine.
Generally on Ubuntu you just need to do two things:
Have PHP installed and php-fpm running as daemon.
Have some webserver running (apache, nginx, caddy whatever) and have it set up so that it points to right folders.
It seems more daunting than it really is. Its more in line
sudo apt update //updating list of instalable packages to current one
sudo apt install php7 //instal php
sudo apt install nginx //install nginx
sudo service php7-fpm start // start php daemon that takes care of php scripts
// make some nginx basic config in /etc/nginx
sudo service nginx start //start nginx with your conf
The above won’t work but these are the general steps. You can find loads of tutorials on this everywhere.
At some point in our lives, we deploy a website to live and it breaks because the environment used for the local build differs from the live environment. My suggestion was totally helpful because it allows the creation of a local environment that is identical to the live server.
Haha, that was probably a misunderstanding, I also thought you suggested using Vagrant on the VPS… and not using Vagrant locally with the same environment as on the VPS.
Anyway, I think we should really keep things separate. One thing is installing Kirby on any kind of server. Setting up and harding a VPS is a completely different story. And so is setting up a local development environment.
Having gone through many local dev hoops, including WAMP, MAMP and friends i got very frustrated with those so for me, the best solution is Vagrant because it’s much closer to a real server. It’s really a matter of personal opinion. I can configure and spin up a full blown environment in a couple of minutes and get to work.
That’s not the point. I actually think Vagrant is a much better solution than things like mamp. Obviously you can spin up server very quickly with Vagrant (thats the point).
What i am saying is that there is guy frustrated with setting up his server and to him mentioning Vagrant might just confuse him because Vagrants usecase is something completely different.
Please, if you want to discuss the pros and cons of using Vagrant, please start a new topic, this has nothing to do with the original question anymore. Thank you!
I wasn’t suggesting that he would. My point was to get his local environment to be as close as possible to his Linode server. That is exactly the point of Vagrant
Apologies I was merely offering the OP some thoughts and it ran away - no thread hijacking intended!
, we can certainly try to improve this, although in many (most?) cases it’s just transferring the files,