Netlify CMS – An open-source CMS for Git workflows
netlifycms.org
netlifycms.org
If the marketing team wants to edit something, they mount the content drive, make changes using their text editor of choice, and are able to preview when they hit Save.
After they make a bunch of changes and add whatever media an engineer copies the changes off of the drive into a commit and deploys to production.
So far it's been working pretty well. The marketing and CS team are all able to edit markdown copy and run it easier through their content editing processes since it's just files. They don't need to learn or care about git. Designers can throw images in the volume without thinking too much about it.
Engineering is happy because they control their git history and commits. When it's time to optimize PNGs, compress assets, etc. the engineer can deal with and deploy to product with confidence.
We also run rspecs against every single page of content to enforce SEO, branding, etc.
Happy to answer questions or write something more detailed about it if others are interested.
How do you do it with windows 10 ?
That's not WebDAV, but using SSH/SFTP. Requires extra software on windows (either an SFTP client, or if you want the filesystem integration specifically there is a version of sshfs for Windows)
Basic WebDAV support is integrated in Windows Explorer, and has been for ages, but there are alternative clients (both paid and free) as well.
As others point out WebDAV is also integrated into Windows Explorer.
The beauty of it is that people don't need to install additional software and almost everybody knows how to use a file system.
The idea never caught on because the people didn't find it as a good solution. Happy to see that somebody, somewhere out there has built exactly this and is happy with the outcome ;)
Cheered me up a lot, thanks for sharing!
The whole thing feels so retro, but it works pretty well and makes it just that much more fun of a solution.
This makes it even more funny, because I thought of that too! Wow, feels like reading an autobiography ;)
Some people have even done a google doc markup like language.
I implemented the "scraping" via a Rake task. When marketing updates a point of comparison, an engineer runs the task which simply downloads a CSV file that is plugged into these pages and a nicely formatted XLXS file that's made available for download for people who want to see all the data in one place.
There's "big data". I call this "tiny data".
> You understand how HTTP cache headers, HTTP/2, and asset fingerprinting can increase speed page load times
Overall meaning is obvious, but “increase speed page load times”—probably meant either increase loading speed or decrease load times.
Are you open to fully remote, by the way? (As in, someone working with you while on the move traveling in SE Asia)
Yep! We are open to remotes that distant. In fact, we have an engineer working with us from Malaysia.
[0]: https://next.smashingmagazine.com/2017/03/a-little-surprise-...
[0]: https://github.com/netlify/netlify-cms/blob/master/docs/exte...
Do you have plans to extend this to a “batteries included” platform? At the moment it's one piece of a puzzle; users must still choose and configure their build and deployment pipeline, which puts it out of reach for less technical users.
To make static site hosting appealing to a wider audience it feels like a click-and-go platform with themes/plugins may be a good direction to follow. I have used https://www.siteleaf.com/ in the past and been impressed with the workflow. I'd love to help contribute to an open version that appealed to a wider non-technical audience.
Wordpress and the whole ecosystem around the LAMP stack did a great job around this and was a big player in building an open web, but the underlying tech stack is way outdated now, and the developer experience is so far off what modern front-end tooling is evolving into, so we aim to build something for a modern stack, that doesn't give up on the fundamental openness of an open-source ecosystem.
{% section %}
::: section
http://spec.commonmark.org/0.26/#container-blocks-and-leaf-b...
I had thought the `::: section` syntax was a recommended approach (if not yet part of the formal spec).
In the past, I have used various home grown solutions to this, but recently I have been using markdown-it and the accompanying plying markdown-it-container. On the CommonMark forums, I see that the ::: syntax is a leading contender, but that CommonMark itself will not address extensions to basic markdown until after the spec reaches 1.0
https://github.com/markdown-it/markdown-it-container
Not an official part of the spec, but certainly something this CMS could support since you'd just parse the markdown it saves with whatever parser you choose with your static generator.
Otherwise this is a really nice CMS & first time I've seen Netlify. I'm recommending we take a look at this as a possible solution to a writer's first & headless/decoupled CMS for our company. It was very easy to add a new content type. I think our non-developers could even do it fairly easily. I also really like your affordable options for hosting, especially the free open source stuff with a custom domain name & HTTPS. I will for sure give that a test run with some stuff.
Is it possible to parse and edit embeds put into the articles via custom widgets? I see in the example how to add a widget to add something to my page. But I don't see how to parse markdown to present an editing to an 'old' widget. I also see that images are non-editable (both image file and alt) once placed into the article.
Is this is a hard limitation or rather widgets are half-baked?
The "fromBlock" property is what detects the insertion from the markdown to present back the widget interface when editing.
There's still some work ahead to make this really smooth, but the idea is to give simple ways to work with shortcodes, etc, without having to be aware of the syntax.
Rendering content blocks in server and then further enhancing them on client-side using a JSON API can be how most sites will be built in future (especially, with ServiceWorkers we would be able to create more fine-grained offline experience too).
I'm also currently working on a project on similar lines, check out the initial blog post for more details - http://www.laktek.com/2016/11/29/introducing-pragma/
Edit: also loved the idea of a kanban board for edit-review-publish process. Might steal that idea ;)
This is exciting to see them work on. I'm disappointed to see that they aren't focusing on designers though. Something like RespondCMS for Netlify hosting would be a superior combo.
Also, reading the Step by Step guide[2] I'd end up giving r/w access to my public keys as well.
Now, I just wake up and maybe I missed something but documentation should make it clearer that you either have to create a dedicated github account, or how to manage permission in a more granular fashion.
[1] https://www.netlifycms.org/docs/test-drive/
[2] https://www.netlify.com/blog/2016/10/27/a-step-by-step-guide...
The r/w access to public keys is specific to setting up continuous deployment from a GitHub repo to Netlify's static hosting service. You can read more about why Netlify requests those permissions for continuous deployment here: https://www.netlify.com/docs/github-permissions/.
While Netlify's continuous deployment is (obviously) the deployment strategy we recommend, you can use the CMS for any static site, as it's totally build/deploy agnostic. You can use the CMS to edit your content and then build that content with Hugo and host on a VPS if you wish. You can also use Netlify to host your content without continuous deployment - it supports updating content with both an in-browser interface and a REST API [1].
The CMS is entirely open source, so you're free to inspect or fork the code - you can find the repository at https://github.com/netlify/netlify-cms/
> … in order to use the CMS, you’ll need to set up authentication with GitHub.
That's the opposite of how oAuth is typically used and I notice that at this point in the process the user has already gone through an oAuth flow when they clicked "Sign in with Github".
I guess I answered my own question. A person could fork a repo and give write access to the fork, preserving their initial copy.
Unfortunately that renders it pretty much useless for me (and probably other non-Github users) if so.
I was planning to deploy my site onto Netlify once done. Wondering if maybe your CMS is a better alternative to Contentful and I should just combine services.
Treating the content like code offers the advantage of being able to easily roll back a website to any one point in time, and I think it generally makes collaboration between designers, coders, and content editors easier.
When developing, it's really nice to just create a new branch and work on the content and design all at the same time.
The aim of this CMS is to hopefully offer the content editing experience of Contentful without requiring an external dependency, while also keeping all aspects of your site tightly integrated with your git workflow.
Works quite nice so far (especially since I didn't need to explain how to optimize the images) but would prefer a open source solution.
Really love what these guys are trying to build: critical mass over static websites. That's what we need.
I am looking around for a smallish CMS, but I got no idea from the introductory pages on whether or not netlify could help me
It's a CMS that works on static sites. Currently it primarily supports GitHub repos for storage, but the plan is to support other alternatives (it already supports pluggable backends, but the GitHub backend is the only one with significant support at this point).
> How does it compare to other CMSes?
- It doesn't require a database - it works on static files.
- It doesn't handle building or serving websites - just editing their content.
- It has a built-in editorial workflow, which allows you to manage publishing and reviewing entries in a sophisticated manner (it uses Git repositories to do this, currently through the GitHub API), where "publishing" means pushing to a specific branch - you're free to build and deploy your website with any tooling you want.
- It supports arbitrary content types and build tools, by allowing you to describe your content in a config file.
- It is itself usable as a simple set of static files - its entire functionality is implemented as a JS application, so there's no server support required to host it beyond serving files. You can also use it as an npm module for more complex workflows (such as adding custom extensions to the CMS).
> After "Find out more" I know now that it does something with Github, but what exactly?
The current primary backend for Netlify CMS is the GitHub API. This means that it allows you to store your files in a GitHub repo, connect Netlify CMS to it, and it will use that repo to store your changes. A build system could then pull that repo to deploy your site. The CMS itself is entirely build and deploy agnostic.
As far as I can see, the only feature this needs that only github provides is pull requests – omitting those would still leave you with a useful CMS, and the information could also be communicated in, for example, branch names. That way, you could conceivably use any client you want to work on the repo.
So instead of implementing Gitlab next, why not make it work with git?
This situation reminds me of email clients and libraries, many of whom now use private APIs of a bunch of providers instead of SMTL and IMAP.
That said, the focus of the CMS team is mostly on online publishing right now - we're trying to make editing static sites accessible enough for everyday users and featureful enough for large publications. I'd love to hear more about your use case and what you were thinking about using Netlify CMS for - you can reply here, raise an issue at https://github.com/netlify/netlify-cms/, or contact me at ben@netlify.com if you'd like to speak privately.
[0]: https://github.com/netlify/netlify-cms/blob/master/example/c...
[1]: https://github.com/netlify/netlify-cms/blob/master/docs/exte...
I've used prismic.io and other such systems in the past, all wonderful. I'm glad to see this is evolving in other ways.