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]

:+1: :)

[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 :+1:

[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?

[omega8cc]

The plan is to make it possible to manage Grav sites via Aegir control panel, but initial implementation will be based on command line wrappers, so it doesn't matter if the Grav own multisite support will be ready.

[me336408]

+1

[memtkmcc]

Our website runs on Grav 1.1.1 since July 20. It is a true relief to be able to use so nicely designed and coded CMS instead of bloated Drupal setup, especially for a website with only 12 pages (!)

You can check it now at https://omega8.cc

Next step: porting and rewriting BOA docs, still available at https://learn.omega8.cc

We have mentioned this at: https://omega8.cc/learn

We are currently porting and rewriting our legacy docs from Drupal to Grav CMS, to make it very easy for the BOA community to improve and expand documentation via standard pull requests on GitHub.

You can see how the new documentation site will look and work on the Learn Grav CMS site.

In the meantime, we are working on a very easy to use Grav support in BOA.

[rhukster]

👍 Looks great! Glad you enjoyed working with Grav :)

[memtkmcc]

@rhukster -- Hi Andy, thank you for the amazing work and effort you have put into this brilliant system. No more excuses to run simple sites on bloated systems (Drupal, WordPress etc.) or too geeky alternatives (Jekyll, Prose, Octopress etc.) Grav strikes a golden balance between them, while being accesible both for geeks and normal people :)

[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 https://github.com/omega8cc/boa/issues/790#issuecomment-182427252 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.

[EdNett]

Hello,

Is this something that you still plan on implementing in BOA? Will it be included in lite? Just to understand it, does implementation in BOA mean that we will add a site through the Octopus GUI (interface) like we do a Drupal site? [ Either with us creating our own grav.version platform and adding it in the Octopus GUI or by your (or one of us) packaging one and including it as an optional installable platform ?] Or will we still have to use the above-shown methods of downloading, extracting and creating our own nginx vhost file? We have a need for a single page which is extremely light and can be cached and can serve potentially millions of hits per day with links to a drupal site sitting either in a folder or on a subdomain. Would grav come close to providing (like 50 + %) the same number of maximum hits per day as a simple page hand-coded in html with minimal and minified css an with image compression for the two to three very light images on the page ? Thanks for updating on this. Lastly, does your usage of Backdrop CMS remove your need or desire to continue to offer a grav usage possibility (rather than "support") ? Thanks, Ed

[omega8cc]

Grav CMS support will be added later this year, maybe even during the summer. It will be managed on command line only.

_{Sent with GitHawk}

[rhukster]

If there’s anything I can do to help, let me know as I’m the creator of Grav CMS. Cheers.

[omega8cc]

Hi Andy,

It's been a long time coming, but after many years of running our own website on Grav, we are absolutely thrilled that Grav support is finally planned and being worked on for BOA! We will be in touch soon.

Best regards,
Adam

_{Sent with GitHawk}

[EdNett]

Great! Thanks.

[EdNett]

Actually, following Yaazkal's suggestions, I got only http 500 errors - regardless of whether I try to install via composer, (as either the o1.ftp or the root user) via wget download unpack and change permissions, etc. Has anyone been able to get this workign manually using boa 5.2.0 ? Thanks. I am able to get a simple index.html page working.

[reswild]

I'm running a couple of Grav sites on one of my BOA severs, but lately I've had to patch Grav in order to make it work with the default BOA PHP configuration. I tried creating an issue about this earlier this year, but the Grav folks didn't seem keen to fix this at their end: https://github.com/getgrav/grav/issues/3797

Also note that there appears to be a typo in the vhost configuration posted above: In order to protect your backup files from direct access, you have to use backup and not backups for the directory name.

[rhukster]

Sorry about this. I’m responsible for merging the Grav PR and it slipped off my radar. I will give it another look.

[rhukster]

With the latest commit by @omega8cc https://github.com/omega8cc/boa/commit/f2922fdfffcf122e95aed878f9a24fa0a38228ea Grav should work no problem.