Grav workflow between developer & content editor

hi there !

i just started using grav for one of my smaller projects and i'm loving it!!! everything is really well documented and quite logical in its structure. but i think i've stumbled upon a usecase that is not (yet?) supported:

after creating the basic structure of the website in terms of templates & markdown-files, i'm now starting to do the styling (mostly twig & css work). i have set up a github-workflow with a webhook and everything runs smoothely (thanks to the excellent tutorial!). local changes get synched via the github desktop app and then deployed to the server.

however: since time is an issue, i would like my co-worker to start putting in content right away, via the admin-panel (she's not the dev-type), while i continue working on the styling. but that would mean, that i'd need something like a post-receive hook on my server, that automatically pushes / merges the "admin-panel"-changes into the github repository, which in turn synchronizes my local working copy.

how would one go about automating a process like this? i've found a couple of similar ques tions in the forum, but never a satisfying answer. and, truth be told, i'm quite new to all this (never ever set up a cms by myself until now, never really worked with git before, etc..).

Whilst you could set her up as a contributor to the GitHub repo, I'd rather suggest that she starts writing the content entirely independent of your dev-work. As you say, she is "not the dev-type", and you would probably be better off adhering to the principle of content being separated from design since she does not need to do any of the development. Your design and functionality should work regardless of the content.

hi gingah, thx for your reply! while i wholeheartedly agree in regards to a strict separation of content and representation (and grav does a very good job with that), my question relates more to the development workflow.

in order to speed up the process i imagined being able to work on grav "from both ends" at the same time. that way she (content editor) would instantly see the changes i (web dev) made to the styling, while i would get her newly added content pushed to my local dev-setup. the advantage of this kind of "concurrent creation" should be a faster pace of development, i would imagine --- IF it can be automated, that is...

do you think it is generally possible, and could you point me in a direction?

has anyone else of you had similar concerns or do you have strictly separated development phases (meaning: no content creation until the programming is done)?

I understand the idea, and to me a staging-area seems most optimal: A webserver (or area of) which hosts a mirror of your most up-to-date (stable) build of the site, where she can use the admin plugin to edit content and see the changes as they roll in. You can then update this staging-server with a newer stable release, that of course does not override or affect the user/pages/ folder.

This would integrate fairly well with your current workflow: You can easily mirror branches or the entirety of changes templates, styles, etc. to the staging-area without affect the content. And more importantly, it requires no technical work on the content-creation end of things. Also, you can supervise and edit content as needed, as well as back it up through Git when needed.

I generally do it concurrently, as you outline, because on most projects I edit the content as well. As chance has it, I am currently working on a project where I will not write most content, so design d oes come first. However, this development is entirely separate from actual content, as placeholders and dummy text work well enough to illustrate how various elements will appear in the final release.

yes, a staging-area is indeed a good idea, although i'm not convinced that a division of contents (user/pages/-folder is off-limits for dev, in order to not produce conflicts) is the way to go. let me try to explain:

(if any of this sounds strangely worded or simply false, it probably is - git is still quite foreign to me, so please pardon my vocab and correct me if you like - thanks!):

besides doing frontend, i also do all visual design for this project. that means that i would like to have all graphics she uploads in the admin-panel "automatically" pushed to github and then into my local repository, in order to easily retouch & optimize them locally with photoshop / sketch. the optimized graphics would then be pushed from my local repository to github and via webhook to the staging server. for that reason, i would need to change the contents of my local user/pages/-folder, thus potentially creating conflict on the server when pushing the new version...

as it is now, i would have to wait for the content-creator to tell me when she uploaded new images, then pull and merge all the new content in /user/pages/-folder into my local repository. from the content-creators perspective, this is no big hassle. but what i as a web designer would be lacking, is a live / nigh-instant visual feedback of the evolution of the content. and because this project is heavily content driven, i feel that structure and styles need to evolve alongside with it, in order to find the most concise presentation.

maybe this is all a bit esoteric, i just thought there could possibly be a way to establish this kind of lively "co-working"-spirit within grav. but maybe that's just me :) thanks for your input anyway, it has been really helpful!

Webhooks from within Grav, ie an action is taking within the admin panel which triggers Git on the server to check for changes or new files. After a period (of minutes, to allow all new files and changes to accumulate) the changes/additions are assembled into a Git commit which is synced between the local server and the main repository.

This would of course have to be coded, and as a solution it requires a lot of work in developing plugins and interfaces to handle the workflow. However, with Grav approaching an API and there already being outlined webhooks for Git-integration, it is basically just a case of assembling the plugin correctly to avoid unnecessarily frequent commits and conflicts.

Another point, related to my previous reply, is that content and development should be branched differently within the repository (or in separate ones). This is in order for changes you make to design and functionality to not conflict or be affected by updates to the content, and for clearly distinct timelines in the development of both.

It is an interesting idea, and should be a chievable if different servers/staging-areas are correctly interfaced and the workflows can be kept relatively clean (you don't want to have to sieve through 50 pull requests or merge conflicts because people are working concurrently).

thanks for your ideas & explanations gingah!
i'm gonna try out branching content and development. gotta brush up on my git skillz first, though ;-) i'm crossing my fingers that some of this makes it into the grav api, that'd be awesome...