Hi all,
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.
