Any chance to install grav compliant to Arch Linux' web application package guidelines

[makuhama]

This is neither a bug report nor a feature request - just a humble question for hints.

Looks like grav's package for Arch Linux has been abandoned. I'm currently contemplating to pick up. Unfortunately I'm unable to install grav in a way that complies with Arch Linux' web application package guidelines. To be compliant would mean

1. Use a dedicated user for the application (e.g. grav).
2. Install most parts of grav in /usr/share/webapps/grav with root:root, i.e. only readable by user grav.
3. GRAV_ROOT/user to be found in /var/lib/grav.
4. GRAV_ROOT/cache to be found in /var/cache/grav.
5. Configuration to be found in /etc/webapps/grav/config (preferrably making /var/lib/grav/config obsolete).
6. Log files to be found in /var/log/grav.
7. Temporary stuff to be found in /var/tmp

Item 1 & 2 are doable. But items 3 and below are problematic. They boil down to

Is it possible to set up grav in way so that certain parts below GRAV_ROOT (e.g. cache) can be located somewhere else (outside the hierarchy below GRAV_ROOT)?

Thanks in advance

(I've already fiddled around a couple of hours with setup.php, env variables like e.g. GRAV_CACHE_PATH and symbolic links - to no avail.)

[mahagr]

File setup.php loads too late for it to be of any use. It was mainly created for multisite setup and thus not suitable here.

I just implemented basic support for running Grav from outside of the webroot. It should be supported from Grav 1.7.10+.

You can use either environment variables or create a PHP file that sets the paths as following

/var/lib/grav/index.php (as an example):

<?php

define('GRAV_WEBROOT', '/var/lib/grav');
define('GRAV_ROOT', '/usr/share/webapps/grav');
define('GRAV_SYSTEM_PATH', GRAV_ROOT . '/system');
define('GRAV_CACHE_PATH', '/var/cache/grav');
define('GRAV_LOG_PATH', '/var/log/grav');
define('GRAV_TMP_PATH', '/var/tmp/grav');
define('GRAV_BACKUP_PATH', GRAV_WEBROOT . '/backups'); // Should be outside webroot really!

include GRAV_ROOT . '/index.php';

Those need to be set also when running the CLI command, though I haven't tested that yet.

In my setup I have copied the following folders and files in /var/lib/grav:

assets/
images/
user/
backups/ (preferably somewhere else)
system/assets/ (symlink)
system/images/ (symlink)
.htaccess
robots.txt
index.php (see above)

and every file which should be visible to the browsers (images, CSS, JS, fonts...), because Grav assumes that all the paths are relative from webroot.

After that streams need to be adjusted to take those paths into account, the easiest may be to prepend the user stream with the path where the assets are located in.

[mahagr]

@makuhama Updated the above example. I got a simple Grav site working with the above commit + some trial and error. CLI is still not working properly and I haven't yet tested anything more complicated, like the admin plugin.

It may differ from how web applications work in Arch (I'm using Ubuntu), so be free to customize the setup further. Also, let me know if anything is still broken.

Plugins can also be installed into a custom folder and they should work also outside webroot, well, as long as you copy the assets into webroot so they are available from the webserver.

PS. I have plans to make a phar package from Grav in the future so this exercise helps me to separate the logic better. It would be cool to be able to serve assets from the phar package (or from the library path), so that they do not need to be copied over.

[mahagr]

setup.php is no longer needed. :)

[makuhama]

@mahagr Wow! Many thanks for your efforts. This is far more than I was hoping for. I will try to test your latest commits soon.

One comment: As far as I understand you are putting stuff accessible by the webserver under /var/lib/grav and PHP code under /usr/share/webapps/grav (roughly - ignoring quite some details). From a packager point of view the separation between /usr/share/webapps/grav and /var/lib/grav should be more about what is provided by the package (i.e. by the developers of the web application) ending up in /usr/share/webapps/grav and all the stuff generated / writeable by the user ending up mainly in /var/lib/grav.

So GRAV_WEBROOT remains /usr/share/webapps/grav. Plugins and themes installed later by the user are stored somewhere below /var/lib/grav. By means of symbolic links from somewhere below /usr/share/webapps/grav to somewhere below /var/lib/grav this user provided content is accessible by the web server.

(This setup is somewhat similar to another web application I use as a model for my efforts.)

[mahagr]

Well, basically /usr/share/webapps/grav contains the whole Grav package (excluding the folders that are needed in webroot, which probably should be in there for backup purposes, but will not be used). What I would do, is to copy all the needed folders to webroot and symlink the two system folders during the first installation only. An upgrade should NEVER touch any of the files in the webroot folder. So after installation /var/lib/grav is all about user-generated content (with the exception of few symlinked files which need to be accessed by the browser).

I think you misunderstood, GRAV_WEBROOT should point to folders accessible by the web server, with all the user-contributed images, CSS, JS and fonts. It is GRAV_ROOT which points to the global installation. Just try my setup, I think it should work. :)

[makuhama]

CLI is still not working properly and I haven't yet tested anything more complicated, like the admin plugin.

I've put all the path definitions into system/defines.php

define('GRAV_ROOT', '/usr/share/webapps/grav');
define('GRAV_SYSTEM_PATH', GRAV_ROOT . '/system');
define('GRAV_CACHE_PATH', '/var/cache/grav');
define('GRAV_BACKUP_PATH', '/var/lib/grav/backup');
define('GRAV_LOG_PATH', '/var/log/grav');
define('GRAV_TMP_PATH', '/var/tmp/grav');

With this even CLI works (At least bin/grav backup and bin/grav cache --all touched the right places.)

Is this a viable option or are there any objections to do so?

[mahagr]

I think it's OK as long as the updates are being done through distro updates. We probably need to find also a way to disable Grav updates from admin, but maybe keep the notification about the available update?

[makuhama]

Thanks for pointing out the upgrade option in the Admin plugin. This upgrade option was not on my radar. I will have to investigate how to disable that. So far I only have a patch for SelfupgradeCommand.php that I apply during packaging. It makes bin/grav selfupgrade spit put an error message that upgrading this way is not possible.

[makuhama]

I'm still contemplating how to deal with the three plugins error, markdown-notices and problems that come bundled with your releases from GitHub. In your opinion: Is it ok to just replace the content of the corresponding directories below $GRAV_ROOT/user/plugins during upgrade?

[mahagr]

You could also put the plugins into system/plugins, they should be loaded from there. I would add individual packages for them, though, as they are upgraded (or even removed) separately from Grav.

[mahagr]

I'm going to respond to your email here as people may be interested to know how to relocate configuration.

Basically, Grav uses streams to locate files, so the idea is to modify lookup paths from it. For that, you need to modify system/streams.yaml or create setup.php file. In principle it works like this:

http://learn.getgrav.local/17/advanced/multisite-setup

I'm using streams.yaml as an axample, PHP examples can be found from the link above.

schemes:
  config:
    type: ReadOnlyStream
    prefixes:
    '': 
      - environment://config
      - user://config
      - /etc/webapps/grav/config
      - system://config

You can further set up environment config for sub-sites, but it's a bit more tricky and likely needs the PHP file due to custom location. Note that the above still use configuration overrides inside the site, but you can prevent that by removing the first 2 paths. Unfortunately, that does break saving any configuration in admin, so a solution is needed if the admin wants to disable editing configuration from admin.

[NicoHood]

Hey guys!
I found this issue, but I am quite lost what this can be used for. My usecase would be to have a grav folder right next to the user folder. This way I can use grav as a git repository that would not touch my user folder on a git pull.

Current setup:

`- /mygravwebsite
 |- (All the grav files
 `- /user
   `- (All my user files)

Target setup:

|- /grav
| `- (All the grav files
`- /user
  `- (All my user files)

How would I need to start the development server, that it correctly picks up the grav and the user folder?

[mahagr]

This issue mainly targets packaging Grav into distribution so that it fits into the application guidelines and can be upgraded from the operating system. I am also using it as an excuse to start separating the application logic so that most of Grav can live outside of webroot (true single installation, multiple sites).

[mahagr]

@makuhama We just released new versions which should fix many of the issues in this thread. :)

[NicoHood]

If that is ready I'd love to see a summary/guide of that. That'd be super nice.

[makuhama]

I was trying really hard to get rid of user://config. I wanted the config stream to look like

schemes:
  config:
    type: ReadOnlyStream
    prefixes:
    '': 
      - environment://config
      - /etc/webapps/grav/config
      - system://config

I was even willing to patch the plugins and CLIs to make this work. But unfortunately it looks as if the hard coded directory /etc/webapps/grav/config was never honoured. As soon as I removed user://config from the the list of locations Grav fell back to system://config.

So for the time being I will stick to my initial solution to symlink /var/lib/grav/user/config (i.e. user://config) to /etc/webapps/grav/config. Never liked that approach but it works.

[mahagr]

Yeah, I know. There are still some hardcoded bits out there, though we've fixed a lot of them since we introduced streams.

I'm thinking of turning Grav 2 into more application-like, meaning that I'd have just a single location outside of webroot for the library and also some locked configuration that cannot be changed from the admin. Of course, the old way would still work, but having Grav in read-only location and outside web root would certainly improve security.

[mahagr]

@makuhama Did you get the packages to work?

[makuhama]

@mahagr Thanks for asking. I'm currently in the fortunate situation to have a bit more to time to work on the task. The Arch Linux package is more or less finished. I'm currently working on an article in Arch Linux' wiki about the Grav package. In the wake of that I'm still polishing the package. When done with the article I'm planning to execute several final tests with the package and the article: clean install, upgrade from v1.6, upgrade v1.7.14 to v1.7.15, apache, nginx, php-fpm, uWSGI. A hell lot of combinations. I will definitely not cover all of them. When all is fine I'm going to publish the package and the article. (But don't ask for timelines.)