I’m in the templating stages of a new side-project (shameless plug) and am trying to figure out if Kirby can do what I need when I’m ready to build it - I’ve only ever built smaller personal sites with Kirby (and loved it), without much need for the panel, or consideration of other people. What I need for this new project is;
To be able to collect multiple articles in to a issue, and publish that issue (by specified users).
To be able to version control everything, taking in to account a local / staging / live environment.
To have a publishing workflow.
The first part of #1 is simple, and what Kirby does best, but would it be better to have one folder for all articles, and one for all issues, link articles to issues, and manually publish everything, one at a time, when the time came?
Question #2 is more tricky - do I ask users to add their work to live, and pull it back to local / staging to merge and push again when I have updates, or ask users to use staging as their environment and push it all live when an issue is ready?
Question #3 is where I think Kirby falls down (without having used the panel, just from what I’ve seen) - there’s no internal revisioning of files by default, no “publish on this date” - is that the trade-off we’re stuck with because of the file based nature of Kirby, or has anyone written a plugin to address any of this?
Sorry for the brain dump - there’s a lot I want to know upfront before I commit to building it in Kirby, get half way in, and realise it’s not going to work the way I need.
I guess you write articles for your issues and then publish your whole issue all at once, right? In that case, it would be most useful to make the articles children of the issues so you can reorganize them easily and have them all together.
If you want to publish the articles in your issues one at a time, it still makes sense to make the articles children of the issues, but you would make use of the visibility attribute of the articles. If you aren’t sure in which issue an article will be published, you can create a “drafts” issue, which is the temporary home of unorganized articles until you move them into a specific issue. This also makes possible to easily publish articles manually. Whether you use a drafts issue, the visibility attribute, automatic publishing based on the date or a combination depends on your workflow.
If you need staging systems and version control, the simplest approach is to create a post-push-hook in your version control server and let your writers push directly to the different branches (master and staging). You won’t need the Panel in that case, because everything happens on the writer’s machines.
If you don’t want your writers to have to use version control, you can write a simple Panel dashboard widget for your staging system that commits changes and pushes them to the live site. @bastianallgeier created such a workflow for one of his client’s sites.
Of course you can implement “publish on that date” with Kirby by filtering out issues/articles with a date field set to a future date in your templates and blocking direct access to these pages (also from your template).
If you have any further questions, don’t hesitate to ask.
While I like that approach, the problem I see here is that currently you can’t move pages from one folder to another when using the panel. Don’t know if there are plans to change this. So this would only work if editors work on their local repos and push the stuff to some remote repo?
If reassigning articles to issues is expected to be a common…issue, I’d simply store all articles in one big folder and assign them to issues using the page field which can easily be updated.
This makes it a bit harder to get a quick overview of which articles belong to an issue within the panel, but you should still be able to use the actual page preview for that.
Edit: If there was a “Pages” field type (to select multiple pages in one field, tag-field style), you could do it the other way around and select articles from within an issue in the panel.
Edit 2: You could use a structure field in the ‘issue’ blueprint to hold links to the articles for that issue. That way you can also easily control the order of articles and add issue-specific meta data to each article. There are so many ways in Kirby to do things!
Thanks for the answers - there’s some stuff there I wasn’t aware I could do in the panel, and some things I hadn’t thought of.
I think, given that articles won’t be moved / duplicated from issue to issue, it makes more sense to have articles as children of a parent issue. My only concern is; can I limit users to be able to make articles shown/hidden, if they can’t do so on the parent? Are rules like that set per level of content?
As for publishing, since I don’t want (and they can’t) users to use version control (I’m the only tech-minded person on the ‘team’ so far), I think the better way to do it is to have users create content on the live www, and for me to use my local and staging sites to update and test code. When an issue is published, I’ll have to rememeber to push its changes to git, and if when I need updated content on staging, to push code/templates changes to live, I’ll have to pull it all down and merge it first.
The other part of the site is tagging articles to ‘Products’, and then having a listing of those products, and all articles that relate to them - that would be easier if articles lived on their own, rather than as children of issues, but isn’t insurmountable the other way around.
Does that make sense and seem logical (and do-able) to everyone?
One thing you might want to do is separate the content folder from the rest, i.e. move it out of the project folder, which can be done easily http://getkirby.com/docs/advanced/customized-folder-setup, so that you can use separate repos for both content and structure. Then you only need to push the content repo to your remote repo whenever a new issue is out (or whatever cycle you want for backing up). And push or pull structural/design changes to/from the structure repo.
As regards limiting user access to editing specific pages, this is currently not possible out of the box. There is some development well under way which might make this possible in the near future but no ETA given yet.