search

topiary-io / topiary

a modern content management system
Other
2 stars 0 forks source link

Add config setting and flag to disable git actions on each save #15

Open doesntgolf opened 8 years ago

doesntgolf commented 8 years ago

I think this is one of the last things preventing me from starting to use topiary for my site.

The config setting can be read with getConfig("whatever"), and there's a standard package for flag. The flag should override the config.

schtauffen commented 8 years ago

I'm wondering if we should, by default, only write the file out to file with "Save", and then have a separate button that says "Publish" which then commits and (if you are working remotely) pushes the current file to remote. Publish would implicitly save. (though "Publish" in this sense might need to be renamed, as the content won't actually go live until its publish date/time, if one is set)

This allows us to easily implement rollbacks (discard changes -> git checkout <filename>) and we could have also then save every 2 seconds after changes are made, a lot like how gdrive does it, without creating a million commits.

doesntgolf commented 8 years ago

I think you're exactly right, that's a great idea. But I still think it makes sense to either have it automatically commit or not (and have a "Publish" button as you describe) controlled by config setting/runtime flag.

Things get a little complicated depending on whether the user is running topiary locally and pushing to production, or running topiary on production, because an all-in-one "publish" button necessarily contains two steps: (1) logging the change (git add/commit), and (2) rebuilding the site (hugo). If the user is running it locally (and deploying to a separate prod server), they'd likely want to rebuild after every file change, but not log. If they're running topiary on prod, they may not want to rebuild or log until they hit the "publish" button.

I think we should support any permutation of these possibilities, but this is why it's really important to have good defaults. To me, it seems to make sense to add/commit and rebuild after every file change by default, so that it functions according to expectations of a typical CMS.

The gdrive-like functionality you describe would be awesome, we just have to make sure it functions correctly within the bounds of possible permutations. Would we need separate buttons for log and rebuild (and possibly deploy?) depending on how things are configured? Or would it make sense to combine them under a single button? (I worry that we might prematurely make things more complicated than necessary. But lots of cool and important possibilities here.)