Add Grav CMS support

[omega8cc]

We have looked for alternatives to make our own website (which is just pages and docs) easier to manage, available for versioning on GitHub to engage community it the BOA docs rewrite (in progress) and after reading about some heavily disappointing experiences with Jekyll from experienced Drupal devs, we have found something which fits precisely:

https://twitter.com/omega8cc/status/633555463188127744
https://twitter.com/omega8cc/status/636487981784801280

Read also: https://attiks.com/blog/grav-an-alternative-for-small-drupal-sites

We need this, and we love this!

[ar-jan]

After reading your tweet I also tried it out, and I like it :)

[omega8cc]

👍 :)

[Pls]

omega8cc, are you planning to migrate http://omega8.cc to Grav before adding support for BOA? Looking like a great fit for docs style site and other small sites 👍

[omega8cc]

Yes, working on it!

https://twitter.com/omega8cc/status/633663242204786688

[omega8cc]

Grav comes with some hairy Nginx config example, which needs to be fixed ;)

[rhukster]

+1 Help with Nginx config would be appreciated for sure. The smaller and simpler the better frankly.

[omega8cc]

We will share simplified and secure Nginx config for Grav, once we have it fully tested.

It should both follow Nginx best practices and mirror also Apache specific protection methods you have in .htaccess already.

[Aciid]

Hey I've used KirbyCMS previously for one-pager experiments.

I'm fairly sure grav would fill the same void and actually looks to be pretty much what kirby offers but much more evolved.

+1 For Composer building accessible productions and usable sites with the power of contributed libraries will add much power and possibilities to this distribution.

Actually most of these features are pretty much defacto what more mature CMS's offer today. So it's refreshing to see so much on a tight package. I'm really keen to give this a go locally and will be anxiously waiting for the release of this as an distribution.

Hopefully configuring the routing of this piece to nginx won't be too much of a pain.

As a curiosity, how are we going to tackle composer distributions and sites in general. For example symfony core consists of hundreds of files in vendor libs. And third party libs rank that to thousands. Gets pretty harsh on the backup side of things indexing all.

+1 Composer vendor-libs should be probably excluded on backboa settings.

( This is something I've been thinking on whilst playing with D8 and D8 modules )

Kind regards; Ilari

[omega8cc]

We will symlink these big libs, similarly like we symlink Drupal core for D7 and D6, I think.

[omega8cc]

By the way, vendor folder in Grav has 1083 items, while Drupal "core" has 17225 items (!)

[rhukster]

Yes Grav uses Symfony, but only a very few bits of it. In our distribution packages we actually strip out most of the extraneous stuff too (tests, docs, extra files, etc).

[mysty]

very excited that @rhukster's Grav is in the BOA roadmap - having both Grav and Drupal on a BOA controlled nginx host sounds unbeatable

[arttus]

Just adding my 2c but this sounds cool! Looking forward to playing:)

[Pls]

omega8cc, have you tried to use gravCMS for your own omega8.cc website? What are the experience so far, any downsides learned comparing to drupal? I see that website is still running on drupal, but maby some work is getting done for migrating and you have some struggle there?

[omega8cc]

There is only some initial progress in our internal tests. The explanation is rather simple -- we just didn't have enough time to integrate it properly yet. Plus, it was announced that Grav will add native multi-site support in 1.1, so we would end up with some duplicate work on our side probably, which would have been deprecated very soon anyway. For details please check http://getgrav.org/blog/grav-1.0-released

[macmladen]

I tried Grav when I read on your tweet and I must say that I was fascinated with it. I tried it locally and also I made it run on my own BOA server very easy by adding it as dynamic site not based on Drupal. And it worked without a problem using a configuration already in vhost_d folder. I installed skeletons to test them and all 26 are installed and running without a single problem (e.g. http://agency.grav.dx.rs/ ). Speed is amazing.

I read that they support multisite now like Drupal but haven't still try to do it myself.

If I can help by testing, please say so, I'd be glad to help.

[yaazkal]

I'll like to share a temporary way to host a Grav CMS in BOA (did I say temporary just for test?) I mean, if you have BOA 2.4.x and can't wait for 3.0.0 to come. I don't know what is going to happen when you upgrade, so make it as your own risk, because for sure the path to host Grav on 3.0.0 will be different and I guess you will not need to create an nginx file like this (can be automated task, I hope).

As @macmladen pointed, is simple as creating the site in the vhost_d folder, just that I'm going to explain how-to.

This example is to host test.yaazkal.com using the Blog Site skeleton of grav. So change the steps as you need it. Also I'm gonna host grav files on /var/www folder just for simplicity and to make no noise on the o1 folder.

1. Go to /var/www and download grav or any of its skeletons from their download section and extract it. Also rename the extracted folder as needed.

     # cd /var/www
     # wget https://github.com/getgrav/grav-skeleton-blog-site/releases/download/1.1.1/grav-skeleton-blog-site-v1.1.1.zip
     # unzip grav-skeleton-blog-site-v1.1.1.zip
     # mv grav-skeleton-blog-site-v1.1.1 test.yaazkal.com
   

2. Change folder ownership so php-fpm can run the script. Note that as I run php 5.5 on my server by default, the user will be www55, change it as you need it.

    # chown -R www55:www-data test.yaazkal.com

1. Create a file in /var/aegir/config/server_master/nginx/vhost.d/. That file can be the name of your site, so for this example, I'll use test.yaazkal.com, and the content of the file will be like this (based on the grav documentation):

server {
    listen *:80;
    index index.html index.php;

    ## Begin - Server Info
    # Where the grav files are located
    root /var/www/test.yaazkal.com; 
    # The domain name
    server_name test.yaazkal.com; 
    ## End - Server Info

    ## Begin - Security
    # deny all direct access for these folders
    location ~* /(.git|cache|bin|logs|backups)/.*$ { return 403; }
    # deny running scripts inside core system folders
    location ~* /(system|vendor)/.*\.(txt|xml|md|html|yaml|php|pl|py|cgi|twig|sh|bat)$ { return 403; }
    # deny running scripts inside user folder
    location ~* /user/.*\.(txt|md|yaml|php|pl|py|cgi|twig|sh|bat)$ { return 403; }
    # deny access to specific files in the root folder
    location ~ /(LICENSE|composer.lock|composer.json|nginx.conf|web.config|htaccess.txt|\.htaccess) { return 403; }
    ## End - Security

    # include some general stuff as php handleling and so on
    include    /var/aegir/config/includes/nginx_compact_include.conf;
}

Adn that's it ! http://test.yaazkal.com is working ! (remember to create the corresponding DNS entries if you are using a subdomain or to point your domain correctly to your BOA server).

Good luck!

[omega8cc]

Still not sure if we should wait for official multisite support:

rhukster Jan 29 18:53
We definitely need better multisite docs, but there are a few places we need to ‘fix’ first. CLI commands for example don’t know anything about multisite, so we need to ensure they do. There are some other places too. Multisite is beta really.. it’s there, but it’s a bit rough around the edges

[macmladen]

Still there is not much information on Grav multi-site development except that 1.1 is now in RC and probably soon out.

How did you exactly plan to include it in BOA, will Grav be a platform within Drupal/BOA so that we can spin new Grav site like we do in Drupal? Or it will be only CLI supported?

[Pls]

Hey @memtkmcc,

Looks great! But I've ran into strange issue. Can you share vhost your are using for grav on BOA system? For some reason I'm getting 504 Bad Gateway every time I hit save on admin when editing pages, same happens on login. Seems every form submit causes it.

Any idea what could be problem? I'm currently using #790 (comment) vhost, which @yaazkal posted here. Cheers for getting Grav to BOA, and amazing work @rhukster, guys you rock! :)

[memtkmcc]

@Pls

It's still a work in progress, because Nginx caching is not really used, and we are using dummy Drupal site for LE integration automation instead of proper Grav specific, but feedback is welcome!

1. Create a dummy Drupal site in Aegir and enable SSL to have LE stuff generated
2. Upload gravcms_vhost_common.conf file to /data/disk/o1/config/includes/
3. Upload a1-domain.com--CDN to /data/disk/o1/config/server_master/nginx/vhost.d/
4. Add domain.com 7.0 line to ~/static/control/multi-fpm.info if you have PHP 7
5. Reload web server: service nginx reload, done!

Note about vhost naming convention: the a1- prefix will make it loaded before the Drupal dummy site vhost, while the Drupal site will guarantee that LE cert is auto-renewed for you. The --CDN suffix is required to avoid having the vhost moved to the /data/disk/o1/undo/ directory during daily BOA cleanup procedures.

CAVEATS: Install and upgrade Grav and its plugins always on command line, but then always fix permissions like shown here! -- Note that o1.70.web is used there, because we are running it on PHP 7, obviously! If you don't use multi-fpm.info to specify PHP version per site, replace o1.70.web with o1.web

Enjoy!

[memtkmcc]

BTW, BOA will automate this for you, soon :)

[Pls]

Wow, can't thank you enough for sharing everything so detailed, cheers for open source! :)

[Pls]

Worked great! What I found is that every step has to be made one by one - placeholder site, version switch, custom vhost creation. Problem was that I already tested grav vhost before and some procedures haven't finished as expected. But after temporarily disabling my custom vhost it went smooth.

You think that disallowing /admin page for everyone except yourself (and other known IPs in vhost) is good practice for a CMS login page? We don't really do it on drupal /user page, so why grav is treated special here? I think this protection is more useful for chive/adminer pages.

You mean install/upgrade only using gravs CLI or composer? Not really familiar which is better, would love to hear what's your upgrade process looks like on omega8.cc grav site ;)

[Pls]

I feel I want to share my grav site launch on BOA, so here it is - https://aparaturosnuoma.lt

Nothing special, small grav site running on latest BOA, it just flies and does the job well. Nice alternative from Drupal :)

[memtkmcc]

Looks nice!

As for the /admin protection, we are using it on our website, like we have used /user protection on our old Drupal site before, but it is optional and will not be included in the automated Grav support in BOA.

We don't use composer directly, always Grav CLI tools.

The upgrade process (via our wrapper for Grav CLI tools) will create a backup copy of the site for you, so it will be possible to revert it, if needed, and will run core and plugins upgrades, permissions fix, etc. on a live site. You could always test it on a local copy first, though.

[zanami]

Couldn't make it work, I guess I'm missing something.
So far the best result was this

An exception has been thrown during the rendering of a template ("Zend OPcache API is restricted by "restrict_api" configuration directive") in "partials/base.html.twig"

I don't use PHP7 (5.6 is sufficient for grav AFAIK)

[omega8cc]

@zanami You must use PHP 7.0 in BOA to make Grav work, as listed in the how-to above. Maybe it should be mentioned more explicitly as a requirement.

[zanami]

Ok I got it now, thanks.

[yaazkal]

Hi, I tried this method today, but at the end I get "too many redirections" so the web browser dosen't load it.

Also I disabled SSL to test and see but again in redirects and then shows a 500 error.

[macmladen]

redirection is in configuration

Too many redirections is always a configuration problem. One of the things mentioned bellow is redirecting in one way then another is redirecting the other.

Redirection sources which contradict one another:

1. DNS - registrant, provider, CDN
2. nginx - web server in configuration
3. PHP - or your scripting code

Usual reasons to redirect in one direction or another:

1. Redirect your http to https
2. Redirect your www to bare domain - http://domain.com to http://www.domain.com
3. Redirect any URI to index.php - for example, http://.wwwdomain.com/user/macmladen to http://www.domain.com/index.php?q=user/macmladen

There could be another source of redirection or reason.

'debug' with curl

Open terminal (hoping you are on Mac/Linux or if on Windows use Cygwin):

$ curl -I www.macmladen.com

HTTP/1.1 301 Moved Permanently
Date: Fri, 04 Nov 2016 05:23:57 GMT
Connection: keep-alive
Set-Cookie: __cfduid=d9f949efad8d5648a6ee5e269711349e61478237037; expires=Sat, 04-Nov-17 05:23:57 GMT; path=/; domain=.macmladen.com; HttpOnly
Location: https://www.macmladen.com/
Server: cloudflare-nginx
CF-RAY: 2fc5a30a97194044-SOF

Obviously, it got redirected (first line, 301 Moved permanently) from default http://www.macmladen.com to https://www.macmladen.com (line Location where is new destination), reason is http to https.

Next, use same command with argument from location

$ curl -I https://www.macmladen.com/
HTTP/1.1 301 Moved Permanently
Date: Fri, 04 Nov 2016 05:28:24 GMT
Content-Type: text/html
Connection: keep-alive
Set-Cookie: __cfduid=d13852fa1205298e2f07134380e48690e1478237303; expires=Sat, 04-Nov-17 05:28:23 GMT; path=/; domain=.macmladen.com; HttpOnly
Location: https://macmladen.com/
X-GitHub-Request-Id: B91F1130:6309:1742E4:581C1C77
Via: 1.1 varnish
Age: 0
X-Served-By: cache-fra1242-FRA
X-Cache: MISS
X-Cache-Hits: 0
X-Timer: S1478237303.934356,VS0,VE92
Vary: Accept-Encoding
X-Fastly-Request-ID: d310608cc5791402ee13e8e8432c2a7d7bd9e819
Server: cloudflare-nginx
CF-RAY: 2fc5a98cbb0f4038-SOF

This time redirection is to use bare domain, from https://www.macmladen.com to https://macmladen.com

Do it again with argument from Location:

$ curl -I https://macmladen.com/
HTTP/1.1 200 OK
Date: Fri, 04 Nov 2016 05:31:34 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Set-Cookie: __cfduid=d76a1b65fea5332ff5a29dac45df1cb271478237493; expires=Sat, 04-Nov-17 05:31:33 GMT; path=/; domain=.macmladen.com; HttpOnly
Last-Modified: Tue, 29 Mar 2016 08:50:37 GMT
Access-Control-Allow-Origin: *
Expires: Fri, 04 Nov 2016 05:41:33 GMT
Cache-Control: max-age=600
X-GitHub-Request-Id: B91F1220:14BC:864A7:581C1D32
Via: 1.1 varnish
Age: 0
X-Served-By: cache-lcy1144-LCY
X-Cache: MISS
X-Cache-Hits: 0
X-Timer: S1478237493.925040,VS0,VE137
Vary: Accept-Encoding
X-Fastly-Request-ID: c2b763fde06e6acf1ff34569ae9cf8f1ba7966ab
Server: cloudflare-nginx
CF-RAY: 2fc5ae2ffd883ff6-SOF

When you get in first line of response 200 OK that means as that URL (location) server will return some html which you could also get in raw form with curl without -Iparameter.

You can see Cloudflare signature meaning that CDN which holds DNS is making redirections.

Your solution

It is not obvious what exactly is making redirection, but you can always see where redirection is leading to so you can figure out how to stop it.

Most probably it could be DNS versus server configuration or they versus your code, PHP in this case which is probably in some configuration.

[yaazkal]

Thanks for your answer @macmladen I guess I checked DNS, server config, etc. I'm gonna redo the process and try again debuggin with curl to see if I can make it work.

Regards !

[yaazkal]

Hi @macmladen it is working now. I guess that a problem I had earlier with php 7.0 maybe was causing some issues. Also the 500 error was resolved by fixing permissions as pointed in the gist file to the folders and files.

Maybe it is necessary to add the tmp directory too to the script.

Regards.

Thanks so much for your time!

[yaazkal]

Also, I just had to point that if you are using CloudFlare, just put SSL Full (strict) on CloudFlare in order that CF recognize and deliver your SSL cert in the BOA server, if not, you can end in a redirection loop.

[macmladen]

Full (Strict) just requires valid certificate, not self signed which are good enough for non-strict. Using free plan, one can only get Cloudflare certificate served, only paid plan servers your certificate.

There are three options if one wishes to turn on encryption:

1. Flexible which uses uncrypted connection from server to Cloudflare and CF certificate to visitor
2. Full which uses any SSL key (regular or self signed) to Cloudflare and CF certificate to visitor
3. Strict which requires valid SSL key from CA to Cloudflare and CF certificate to visitor

Your plan does not allow you to upload any SSL certificates, but you may order an auto-renewing certificate or upgrade to the Business plan to enable this feature.

Usage of Cloudflare Crypto (and their SSL) can make redirection loop, especially if one manages http to https or bare domain to www or other way around. If one needs to enforce https maybe the best place is Page rules (free plan allows three rules) and choose Always use HTTPS.