Big refactoring - #366
Conversation
…content directory This will lend itself better to use in a container. This is still WIP because we need to add support for allowing users to have the Staytus web server serve their own assets (staticly) and seperate the views a bit to allow for smaller components to be overriden when needed.
|
Is there a particular reason as to why the next version of Staytus must be in Docker? In my use case, my Staytus instance runs using Phusion Passenger, which is a module for Apache [httpd 2.4]. Therefore, I don't use Procodile to run a webserver instance for it. Running Staytus inside docker is not practical, due to the virtual server being set up to work only with a non-docker environment. I would hope that there would be a way to run Staytus without having to be forced to using Docker though, especially as my compute server doesn't have the RAM capacity to run a virtual machine within an existing virtual machine and it would require all sorts of changes to make Phusion Passenger work with a service inside of a docker instance. |
The maintenance burden for me to support installing it in unknown environments is primary driver. In order to ensure timely updates, I need to make it as easy as possible to develop and distribute. However, I don't have any plan to do anything that'll stop Staytus working using whatever means you feel most appropriate. If you want to clone the repo, checkout a tag and run it on Passenger, that's fine but you'll need to configure all that yourself (like you're doing already). |
Okay fair enough yeah. As you rightly indicated, I simply clone the repo and then run the appropriate bundle/exec commands and then register the app in Passenger which works fine for the moment, and as long as that continues to be possible, I'll be 👍 with that. Thanks for the reply! |
|
Any progress so far? ;-) |
|
@adamcooke first of all thanks for this great tool 🙇 Thanks and have a great week! |
|
Hi @jarthod - I'm still keen do some work on Staytus, I just need a bit of time to sit down with it. We use it where I work so still very much in use. I can't promise anything at the moment but I do hope to have some time to look at it properly in the next couple of months. |
|
@adamcooke ok thanks for the quick response, glad to hear that :) |
|
@adamcooke I think I'll have to start doing a few upgrades on my end because it's getting a bit tricky to host EOL versions of Ruby and Rails. I'm not gonna write any PR for now as it doesn't seem to be a good time for you but if you ever want to resume the maintenance (and get my updates) or are looking for more maintainers to help you, let me know. |
4 participants
I'm giving Staytus a bit of an overhaul. This branch will be following those changes. The key things that I'm looking to introduce during this are relatively minor from a UI point of view by huge from actually running the application.
Staytus will only support using containers to run it. I will provide containers and full documentation on how to run Staytus. Similar to work I've recently done on Postal.
The concept of having multiple themes will go away. Instead, the default theme will move back into the application but will allow users to override any part of it themselves by placing appropriate template files in the
content/viewsdirectory. This will be more compatible with running Staytus in a container.Outstanding issues and PRs will be closed or merged as appropriate.
A new documentation site will be established at
docs.staytus.co.A new HTTP API will be added (powered by Apia and documentation published).
Staytus 2.0 will be released to include these change. The current version of Staytus in the
masterbranch will be frozen because some people have installed Staytus by checking out this branch. A newmainbranch will be established to track all future changes.